* RE: /proc/cpuinfo and hyperthreading
From: Scott Robert Ladd @ 2002-12-16 14:36 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021216140809.GE11616@suse.de>
Dave Jones wrote:
> Looks like you're either missing some ACPI config options, or
> you haven't updated the BIOS yet. On 2.5.51 with latest BIOS on
> the same box, I get..
Everything is fixed. No, I hadn't upgraded the BIOS; when I asked a contact
at Intel about the problem, I was told told me that BIOS was the latest.
I should have know better than to believe them!
Thank you very much; cat /proc/cpuinfo now reports two CPUs.
..Scott
^ permalink raw reply
* Re: [PATCH] envy24control.[ch] update for hoontech cards.
From: Jaroslav Kysela @ 2002-12-16 14:25 UTC (permalink / raw)
To: Henry Walpool; +Cc: alsa-devel@lists.sourceforge.net
In-Reply-To: <20021216001517.2A6C93A9D@sitemail.everyone.net>
On Sun, 15 Dec 2002, Henry Walpool wrote:
> The Hoontech Media 7.1 card has a consumer/professional option at least
> under windows. I would assume that with the correct information from
> hoontech one could program this under alsa. Of course I don't have a
> clue, I'm just guessing here.
It's possible that newer cards can drive this control via GPIO, but I have
no information about the Media 7.1 version.
Jaroslav
> --- Jaroslav Kysela <perex@suse.cz> wrote:
> >On Sat, 14 Dec 2002, Henry Walpool wrote:
> >
> >> Added some code to block out the error messages for the hoontech cards
> >> when someone tries to access the professional/consumer option. I tried
> >> to get the information from hoontech but no luck. I don't think it would
> >> be that hard to add the correct code to enable these functions but
> >> hoontech is not talking unfortunately. Hoontech even stopped responding
> >> to my e-mails. The last response I got was "e-mail the alsa-developers".
> >> "They have all the information about hoontech cards already."
> >
> >The original hoontech cards have hardwired support (in hardware) for
> >consumer mode only.
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Changing MAC Addresses
From: Andrew J. Meader @ 2002-12-16 14:24 UTC (permalink / raw)
To: Sam Johnston, netfilter
In-Reply-To: <3DF16CDD.5000400@aos.net.au>
Sam,
What does /sbin/ifconfig -a tell you?
Andy
Sam Johnston wrote:
> Afternoon all,
>
> I'm not sure if this is the best forum for this question as it is not
> necessarily directly related to Netfilter, but I can't think of
> anywhere else I might find anyone capable of answering it, so here goes.
>
> I have a bunch of xboxes running linux which all have the same MAC
> address: 00:00:00:00:00:00. This causes obvious problems when more
> than 1 machine is on any one segment. I'm led to believe I can work
> around the problem by putting something like:
>
> /sbin/ifconfig eth0 hw ether 00:50:f2:ab:cd:ef up
>
> fairly early in the boot process (specifically, I've chosen the pre-up
> directive in /etc/network/interfaces as they're running Debian).
>
> When I do this I'm able to see the MAC<->IP mapping in the ARP table
> of another machine, but it doesn't respond. I figure that something
> somewhere is remembering the old MAC address and dropping anything
> that doesn't match, although I don't know enough about low level
> networking in linux to be sure.
>
> Any suggestions would be appreciated.
>
> Sam
^ permalink raw reply
* Re: transparent squid & iptables
From: Andrew J. Meader @ 2002-12-16 14:23 UTC (permalink / raw)
To: Abylai Ospan, netfilter
In-Reply-To: <008201c2a420$487f82a0$8902010a@alkaloid>
Hi,
Here is how I am doing it and it works nicely:
iptables -t nat -A PREROUTING -i $LOCAL -p tcp --dport 80 -j REDIRECT \
--to-port 3128
echo "PREROUTING: enableling transparent http proxy"
Have fun!
Andy
Abylai Ospan wrote:
> Hello, All.
>
> We tried to make transparent squid on 127.0.0.1 and REDIRECT (or DNAT)
> in iptables but iptables redirect pakets to the received interface IP.
>
> In the iptables:
> iptables -t nat -A PREROUTING -p TCP --dport 80 -j REDIRECT 3128
>
> For example:
> packet from user (IP: 10.0.0.5) to www.ru <http://www.ru>:80 received
> on eth0 (IP: 10.0.0.1). Packet redirected to the 10.0.0.1:3128 but
> squid listen on 127.0.0.1:3128 so nothing work ;-(
>
> How we can redirect packet to the 127.0.0.1 port 3128 in iptables ?!
>
> wbr, Abylai
> NetUP Systems
> Moscow, Russia
^ permalink raw reply
* Re: [parisc-linux] problems with PCI IDE controller
From: Alan Cox @ 2002-12-16 15:03 UTC (permalink / raw)
To: John Marvin; +Cc: parisc-linux
In-Reply-To: <200212160609.XAA18500@udlkern.fc.hp.com>
On Mon, 2002-12-16 at 06:09, John Marvin wrote:
> > On Sat, 2002-12-14 at 13:10, Matthew Wilcox wrote:
> > > > hp-c240 login: Uniform Multi-Platform E-IDE driver Revision: 6.31
> > > > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> > > > PDC20268: IDE controller on PCI bus 00 dev 08
> > > > PDC20268: chipset revision 2
> > > > PDC20268: not 100% native mode: will probe irqs later
> >
> > Is this a plug in card. For some reason it has been left in non native
> > mode so won't work as a plug in board.
>
> I don't think this is a problem. I have a similar card in my home PC, and
> it prints the same thing (re: not 100% native mode). Here is an excerpt
> from my PC's boot messages running 2.4.19:
A PC is a very different thing
In legacy mode the PCI BAR registers are ignored, the I/O decode is at
0x170 etc and interrupts are flagged by the ISA legacy not by the PCI
bus.
That isnt going to work very well on your average PA-RISC box. Most
probably you want to force the chip into native mode on pa-risc
hardware.
^ permalink raw reply
* RE: 823 Video Controller Driver - where ?
From: Steven Blakeslee @ 2002-12-16 14:16 UTC (permalink / raw)
To: Steve Rossi; +Cc: Embedded Linux PPC List
We have Linux frame buffer drivers for our 823E(LITE DW) and our
IBM405GP(EP405PC).
-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Friday, December 13, 2002 11:43 AM
To: Steve Rossi
Cc: Embedded Linux PPC List
Subject: Re: 823 Video Controller Driver - where ?
Dear Steve,
in message <3DFA05C3.30703@ccrl.mot.com> you wrote:
>
> I've seen some reference on the list regarding a driver for the 823
> Video Controller -
> i.e.
>
http://lists.linuxppc.org/results.html?restrict=linuxppc-embedded&words=vid8
23
> however I've been unable to locate the source to vid823.c
It is my understanding that this driver is available with and for
some EP board only, and obviously not available for free.
> apparently this question was asked before:
> http://lists.linuxppc.org/linuxppc-embedded/200201/msg00164.html
> and the answer was that its in the 2_4_devel tree, but I was unable to
> find it in a recent snapshot of the tree (I'm unable to get the tree
I haven't found anything either when I searched some time ago.
> I'm looking for a driver for the video controller to output to an NTSC
> encoder. Am I just missing something?
> Anyone know where I can get vid823.c (or whatever it might be called
> now) and whether its a true framebuffer driver?
We have a video controller driver in our source tree (module
linux-2.4 on our CVS server), see arch/ppc/8xx_io/video823.c
Note: the code relies on some initialization performed by the U-Boot
boot loader, and it has never been tested yet with NTSC. But it
should be a starting point at least.
And yes, it is a true framebuffer driver, although it uses the
awkward YUYV video mode format only.
Hope this helps.
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
God may be subtle, but He isn't plain mean. - Albert Einstein
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [2.4.20] via82cxxx goes postal and locks system, no full duplex(?)
From: Alan Cox @ 2002-12-16 14:54 UTC (permalink / raw)
To: Mark Rutherford; +Cc: Linux Kernel Mailing List
In-Reply-To: <3DFBFD61.1B367CD2@justirc.net>
On Sun, 2002-12-15 at 03:56, Mark Rutherford wrote:
> this is the second failure in getting a via board to work.
> I also have a kt400/8235 machine that has no driver, so im really
> screwed :(
8235 is supported in the latest -ac code. I sent Jeff the patches, or
by ALSA
^ permalink raw reply
* Re: 2.4.21-pre1 broke the ide-tape driver
From: Alan Cox @ 2002-12-16 14:53 UTC (permalink / raw)
To: Mikael Pettersson; +Cc: m.c.p, Linux Kernel Mailing List, Marcelo Tosatti
In-Reply-To: <200212152338.AAA24823@harpo.it.uu.se>
On Sun, 2002-12-15 at 23:38, Mikael Pettersson wrote:
>
> On Sun, 15 Dec 2002 02:23:34 +0100, Marc-Christian Petersen wrote:
> >> Kernel 2.4.21-pre1 broke the ide-tape driver: the driver
> >> now hangs during initialisation. 2.2 kernels (with Andre's
> >> IDE patch) and 2.4 up to 2.4.20 do not have this problem.
> >> My box has a Seagate STT8000A ATAPI tape drive as hdd;
> >> hdc is a Philips CD-RW, and the controller is ICH2 (i850 chipset).
> >http://linux.bkbits.net:8080/linux-2.4/patch@1.828?nav=index.html|ChangeSet@-7d|cset@1.828
>
> Addendum: this patch fixes the init-time hang, and ide-tape does
> seem to work fine, but 'rmmod ide-tape' oopses -- 2.4.20-ac2 also
> oopses on 'rmmod ide-tape'.
I don't unfortunately have any ide-tape devices. I'll take a look though
^ permalink raw reply
* Re: IDE-CD and VT8235 issue!!!
From: AnonimoVeneziano @ 2002-12-16 14:13 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: linux-kernel
In-Reply-To: <20021216141945.A32729@ucw.cz>
Vojtech Pavlik wrote:
>On Mon, Dec 16, 2002 at 02:19:56PM +0100, AnonimoVeneziano wrote:
>
>
>>>>Thanks for all your effort here. It's great to see such a good
>>>>community.
>>>>
>>>>
>>>If you can, please try 2.4.20 with this patch.
>>>
>>>
>>>
>>This patch works great!! I've solved with this patch, very good work
>>
>>Thank you very much Pavlik!
>>
>>
>
>Can you try another patch (on top of the previous one?)? It might still
>work, and be less intrusive ... (attached)
>
>
>
I don't know what u have changed in this patch, but this work great too. ;-)
Thank you very much again
Byez
^ permalink raw reply
* Re: /proc/cpuinfo and hyperthreading
From: Dave Jones @ 2002-12-16 14:08 UTC (permalink / raw)
To: Scott Robert Ladd; +Cc: Linux Kernel Mailing List
In-Reply-To: <FKEAJLBKJCGBDJJIPJLJCEJPDLAA.scott@coyotegulch.com>
On Sun, Dec 15, 2002 at 10:58:12PM -0500, Scott Robert Ladd wrote:
> During boot, the system reports:
> Dec 15 14:30:34 Tycho kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00]
> enabled)
> Dec 15 14:30:34 Tycho kernel: Processor #0 15:2 APIC version 16
> Dec 15 14:30:34 Tycho kernel: ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01]
> enabled)
> Dec 15 14:30:34 Tycho kernel: Processor #1 15:2 APIC version 16
> Dec 15 14:30:34 Tycho kernel: Building zonelist for node : 0
Looks like you're either missing some ACPI config options, or
you haven't updated the BIOS yet. On 2.5.51 with latest BIOS on
the same box, I get..
Dec 12 16:28:55 tetrachloride kernel: Processor #1 15:2 APIC version 16
Dec 12 16:28:55 tetrachloride kernel: ACPI: LAPIC_NMI (acpi_id[0x01] polarity[0x0] trigger[0x0] lint[0x1])
Dec 12 16:28:55 tetrachloride kernel: ACPI: LAPIC_NMI (acpi_id[0x02] polarity[0x0] trigger[0x0] lint[0x1])
Dec 12 16:28:55 tetrachloride kernel: ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0])
Dec 12 16:28:55 tetrachloride kernel: IOAPIC[0]: Assigned apic_id 2
Dec 12 16:28:55 tetrachloride kernel: IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, IRQ 0-23
Dec 12 16:28:55 tetrachloride kernel: ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x1] trigger[0x3])
Dec 12 16:28:55 tetrachloride kernel: ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0] trigger[0x0])
Dec 12 16:28:55 tetrachloride kernel: Using ACPI (MADT) for SMP configuration information
Dec 12 16:28:55 tetrachloride kernel: Building zonelist for node: 0
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: /proc/cpuinfo and hyperthreading
From: Richard B. Johnson @ 2002-12-16 14:10 UTC (permalink / raw)
To: Brian Jackson; +Cc: Scott Robert Ladd, Linux Kernel Mailing List
In-Reply-To: <20021216135453.3823.qmail@escalade.vistahp.com>
On Mon, 16 Dec 2002, Brian Jackson wrote:
> You could always boot once with nosmp and run some benchmarks and then
> reboot (with smp) and run some more benchmarks, and see if there is a
> difference.
>
> --Brian Jackson
>
>
> Scott Robert Ladd writes:
>
> > Zwane Mwaikambo wrote:
> >> It's ok.
> >
> > I'm not so sure.
> >
> > To get the most benefit from two logical CPUs, don't I need the kernel to
> > operate as a 2-CPU SMP system?
> >
> > Windows XP initializes the system as SMP with two CPUs; when I run an OpenMP
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
How do you know this? How can I learn what Windows does with
Win/2000/professional? The only way I know I have two CPUs is when the
machine fails to reboot because the file-system has been completely
trashed by the two CPUs banging on it at the same time. The solution has
been to remove one CPU. M$ claims; "Windows will over-power the system
if two CPUs are present...." Direct quote. If you have two logical
CPUs, you can't remove one, therefore, unless M$ has fixed the problem(s)
in XP, you can't use Windows with two logical CPUs, i.e., hyperthreading.
> > application under Windows, it reports two CPUs and a maximum of two threads.
> > Under Linux,
> >
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
* Problems with CONFIG_PREEMPT
From: Colin.Helliwell @ 2002-12-16 13:58 UTC (permalink / raw)
To: linux-mips
I've been porting the MIPS kernel to our system-on-chip hardware
(4KEc-based) and have encountered a problem with a pre-emptible patch. The
original kernel was the 2.4.19 from the CVS server, onto which I applied
Robert Love's preemptible patch (preempt-kernel-rml-2.4.19-2.patch), plus
the addition of a #include to softirq.h, and a missing definition for
release_irqlock() in hardirq.h.
I've found that when CONFIG_PREEMPT is set, it no longer loads the
(non-compressed) initrd correctly - about 1.8MB through loading (2MB total)
I get a Data Bus Error. A typical call trace shown by the oops is shown
below, and looks a little 'confused' to me, so I'm thinking there may be
some stack corruption going on?
Address Function
801174fc tasklet_hi_action
801af0a4 printChipInfo
801af0a4 printChipInfo
8013bf50 sys_write
801089c4 stack_done
80108b28 reschedule
801133d0 _call_console_drivers
80113ad8 release_console_sem
80113848 printk
801506b8 sys_ioctl
801af0f8 printChipInfo
8014ccd4 sys_mkdir
801af0a4 printChipInfo
80100470 init
80100470 init
80100840 prepare_namespace
80100470 init
8010049c init
8010352c kernel_thread
80100420 _stext
8010351c kernel_thread
I wondered if anyone had any thoughts about what might be causing this, or
had seen this occuring before - were there perhaps some changes made just
after this point in time (now in the 2.5.x kernel)?
Thanks.
^ permalink raw reply
* Re: possible problems with rc6 aplay
From: Takashi Iwai @ 2002-12-16 13:57 UTC (permalink / raw)
To: Paul Davis; +Cc: Mark Knecht, martin-langer, Alsa-Devel, swpatrick
In-Reply-To: <E18NvZT-0004yb-00@sc8-sf-list1.sourceforge.net>
At Mon, 16 Dec 2002 08:49:35 -0500,
Paul Davis wrote:
>
> >Martin,
> > That might certainly be an answer. How would this amixer switch get
> >st in the first place? I wouldn't mind doing it by hand once as long as
> >it was then loaded after that.
>
> what you want is a short startup script (typically in somewhere under
> /etc/rc.d, but unfortunately this varies somewhat from linux
> distribution to linux distribution). it would look like this:
>
> #!/bin/sh
>
> HAMMERFALL=0 # change to match the card number of the
> # Hammerfall, as shown in /proc/asound/cards
> CLOCK_MODE=0 # auto-sync, the default condition.
> CLOCK_MODE_NAME="autosync"
>
> case $1 in
> start) if [ -f /some/path/to/this-host-is-master ] ; then
> CLOCK_MODE=1
> CLOCK_MODE_NAME="master"
> else
> CLOCK_MODE=2
> CLOCK_MODE_NAME="word clock"
> fi
> echo "Setting Hammerfall to $CLOCK_MODE_NAME mode ..."
> amixer -c $HAMMERFALL cset \
> iface=PCM,name='Sync Mode',numid=7 $CLOCK_MODE
> esac
> exit 0
>
> then, just create the file /some/path/to/this-host-is-master on one
> machine, and it will automatically set the Master switch when it boots
> up. the other machine will remain in AutoSync mode - if they are
> connected via word clock, you probably want to change that as well,
> using the same script.
the standard alsasound init script can call a card-dependent script
under /etc/alsa.d as the last initialization phase. for example, you
can create the file above as /etc/alsa.d/rme9652 (with exec bit). as
other examples, you can load the soundfont on this script for emu10k1
or sbawe.
many distributions use /etc/sysconfig/XXX file for a local
configuration, btw. in this style, create a file
(e.g. /etc/sysconfig/rme9652) containing the variable definitions such
like:
HAMMERFALL=0
CLOCK_MODE=1
CLOCK_MODE_NAME="master"
and call ". /etc/sysconfig/rme9652" at the beginning of the script.
ciao,
Takashi
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: [Oops 2.5.51] PnPBIOS: cat /proc/bus/pnp/escd
From: Dave Jones @ 2002-12-16 13:58 UTC (permalink / raw)
To: Paul, Linux Kernel Mailing List
In-Reply-To: <20021215230344.GE1432@squish.home.loc>
> 'cat /proc/bus/pnp/escd' consistantly produces this:
> EIP: 0088:[<00007b74>] Not tainted
You blew up in BIOS code. Your BIOS has a crap PNPBIOS implementation.
Send the output of dmidecode[1] and it can get added to the blacklist.
[1] http://people.redhat.com/arjanv/dmidecode.c
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: possible problems with rc6 aplay
From: Paul Davis @ 2002-12-16 13:49 UTC (permalink / raw)
To: Mark Knecht; +Cc: martin-langer, Alsa-Devel, swpatrick
In-Reply-To: <1040040264.1358.8.camel@Godzilla>
>Martin,
> That might certainly be an answer. How would this amixer switch get
>st in the first place? I wouldn't mind doing it by hand once as long as
>it was then loaded after that.
what you want is a short startup script (typically in somewhere under
/etc/rc.d, but unfortunately this varies somewhat from linux
distribution to linux distribution). it would look like this:
#!/bin/sh
HAMMERFALL=0 # change to match the card number of the
# Hammerfall, as shown in /proc/asound/cards
CLOCK_MODE=0 # auto-sync, the default condition.
CLOCK_MODE_NAME="autosync"
case $1 in
start) if [ -f /some/path/to/this-host-is-master ] ; then
CLOCK_MODE=1
CLOCK_MODE_NAME="master"
else
CLOCK_MODE=2
CLOCK_MODE_NAME="word clock"
fi
echo "Setting Hammerfall to $CLOCK_MODE_NAME mode ..."
amixer -c $HAMMERFALL cset \
iface=PCM,name='Sync Mode',numid=7 $CLOCK_MODE
esac
exit 0
then, just create the file /some/path/to/this-host-is-master on one
machine, and it will automatically set the Master switch when it boots
up. the other machine will remain in AutoSync mode - if they are
connected via word clock, you probably want to change that as well,
using the same script.
if you need more help with this, let me know. this is one of those
areas where linux and its command line orientation proves so powerful
(though to be fair, its probably possible to do something vaguely
similar on windows, but not using such general-purpose tools).
--p
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* [patch] Make rt_cache_stat use kmalloc_percpu
From: Ravikiran G Thirumalai @ 2002-12-16 13:52 UTC (permalink / raw)
To: David S. Miller ; +Cc: linux-kernel, netdev, dipankar, Andrew Morton
Hi,
Here's another patch to use kmalloc_percpu. As usual, this removes
NR_CPUS bloat, can work when modulized and helps node local allocation.
Thanks,
Kiran
D: Name: rtstats-2.5.52-1.patch
D: Author: Ravikiran Thirumalai
D: Description: Make rt_cache_stat use kmalloc_percpu
include/net/route.h | 6 +++-
net/ipv4/route.c | 71 +++++++++++++++++++++++++++++-----------------------
2 files changed, 45 insertions(+), 32 deletions(-)
diff -ruN -X dontdiff linux-2.5.52/include/net/route.h rtstats-2.5.52/include/net/route.h
--- linux-2.5.52/include/net/route.h Mon Dec 16 07:37:42 2002
+++ rtstats-2.5.52/include/net/route.h Mon Dec 16 14:56:01 2002
@@ -102,7 +102,11 @@
unsigned int gc_ignored;
unsigned int gc_goal_miss;
unsigned int gc_dst_overflow;
-} ____cacheline_aligned_in_smp;
+};
+
+extern struct rt_cache_stat *rt_cache_stat;
+#define RT_CACHE_STAT_INC(field) \
+ (per_cpu_ptr(rt_cache_stat, smp_processor_id())->field++)
extern struct ip_rt_acct *ip_rt_acct;
diff -ruN -X dontdiff linux-2.5.52/net/ipv4/route.c rtstats-2.5.52/net/ipv4/route.c
--- linux-2.5.52/net/ipv4/route.c Mon Dec 16 07:38:23 2002
+++ rtstats-2.5.52/net/ipv4/route.c Mon Dec 16 16:14:09 2002
@@ -195,7 +195,7 @@
static unsigned rt_hash_mask;
static int rt_hash_log;
-struct rt_cache_stat rt_cache_stat[NR_CPUS];
+struct rt_cache_stat *rt_cache_stat;
static int rt_intern_hash(unsigned hash, struct rtable *rth,
struct rtable **res);
@@ -319,24 +319,26 @@
int len = 0;
for (i = 0; i < NR_CPUS; i++) {
+ if (!cpu_possible(i))
+ continue;
len += sprintf(buffer+len, "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x \n",
dst_entries,
- rt_cache_stat[i].in_hit,
- rt_cache_stat[i].in_slow_tot,
- rt_cache_stat[i].in_slow_mc,
- rt_cache_stat[i].in_no_route,
- rt_cache_stat[i].in_brd,
- rt_cache_stat[i].in_martian_dst,
- rt_cache_stat[i].in_martian_src,
-
- rt_cache_stat[i].out_hit,
- rt_cache_stat[i].out_slow_tot,
- rt_cache_stat[i].out_slow_mc,
-
- rt_cache_stat[i].gc_total,
- rt_cache_stat[i].gc_ignored,
- rt_cache_stat[i].gc_goal_miss,
- rt_cache_stat[i].gc_dst_overflow
+ per_cpu_ptr(rt_cache_stat, i)->in_hit,
+ per_cpu_ptr(rt_cache_stat, i)->in_slow_tot,
+ per_cpu_ptr(rt_cache_stat, i)->in_slow_mc,
+ per_cpu_ptr(rt_cache_stat, i)->in_no_route,
+ per_cpu_ptr(rt_cache_stat, i)->in_brd,
+ per_cpu_ptr(rt_cache_stat, i)->in_martian_dst,
+ per_cpu_ptr(rt_cache_stat, i)->in_martian_src,
+
+ per_cpu_ptr(rt_cache_stat, i)->out_hit,
+ per_cpu_ptr(rt_cache_stat, i)->out_slow_tot,
+ per_cpu_ptr(rt_cache_stat, i)->out_slow_mc,
+
+ per_cpu_ptr(rt_cache_stat, i)->gc_total,
+ per_cpu_ptr(rt_cache_stat, i)->gc_ignored,
+ per_cpu_ptr(rt_cache_stat, i)->gc_goal_miss,
+ per_cpu_ptr(rt_cache_stat, i)->gc_dst_overflow
);
}
@@ -592,11 +594,11 @@
* do not make it too frequently.
*/
- rt_cache_stat[smp_processor_id()].gc_total++;
+ RT_CACHE_STAT_INC(gc_total);
if (now - last_gc < ip_rt_gc_min_interval &&
atomic_read(&ipv4_dst_ops.entries) < ip_rt_max_size) {
- rt_cache_stat[smp_processor_id()].gc_ignored++;
+ RT_CACHE_STAT_INC(gc_ignored);
goto out;
}
@@ -664,7 +666,7 @@
We will not spin here for long time in any case.
*/
- rt_cache_stat[smp_processor_id()].gc_goal_miss++;
+ RT_CACHE_STAT_INC(gc_goal_miss);
if (expire == 0)
break;
@@ -683,7 +685,7 @@
goto out;
if (net_ratelimit())
printk(KERN_WARNING "dst cache overflow\n");
- rt_cache_stat[smp_processor_id()].gc_dst_overflow++;
+ RT_CACHE_STAT_INC(gc_dst_overflow);
return 1;
work_done:
@@ -1387,7 +1389,7 @@
if (!LOCAL_MCAST(daddr) && IN_DEV_MFORWARD(in_dev))
rth->u.dst.input = ip_mr_input;
#endif
- rt_cache_stat[smp_processor_id()].in_slow_mc++;
+ RT_CACHE_STAT_INC(in_slow_mc);
in_dev_put(in_dev);
hash = rt_hash_code(daddr, saddr ^ (dev->ifindex << 5), tos);
@@ -1472,7 +1474,7 @@
}
free_res = 1;
- rt_cache_stat[smp_processor_id()].in_slow_tot++;
+ RT_CACHE_STAT_INC(in_slow_tot);
#ifdef CONFIG_IP_ROUTE_NAT
/* Policy is applied before mapping destination,
@@ -1629,7 +1631,7 @@
}
flags |= RTCF_BROADCAST;
res.type = RTN_BROADCAST;
- rt_cache_stat[smp_processor_id()].in_brd++;
+ RT_CACHE_STAT_INC(in_brd);
local_input:
rth = dst_alloc(&ipv4_dst_ops);
@@ -1674,7 +1676,7 @@
goto intern;
no_route:
- rt_cache_stat[smp_processor_id()].in_no_route++;
+ RT_CACHE_STAT_INC(in_no_route);
spec_dst = inet_select_addr(dev, 0, RT_SCOPE_UNIVERSE);
res.type = RTN_UNREACHABLE;
goto local_input;
@@ -1683,7 +1685,7 @@
* Do not cache martian addresses: they should be logged (RFC1812)
*/
martian_destination:
- rt_cache_stat[smp_processor_id()].in_martian_dst++;
+ RT_CACHE_STAT_INC(in_martian_dst);
#ifdef CONFIG_IP_ROUTE_VERBOSE
if (IN_DEV_LOG_MARTIANS(in_dev) && net_ratelimit())
printk(KERN_WARNING "martian destination %u.%u.%u.%u from "
@@ -1700,7 +1702,7 @@
martian_source:
- rt_cache_stat[smp_processor_id()].in_martian_src++;
+ RT_CACHE_STAT_INC(in_martian_src);
#ifdef CONFIG_IP_ROUTE_VERBOSE
if (IN_DEV_LOG_MARTIANS(in_dev) && net_ratelimit()) {
/*
@@ -1749,7 +1751,7 @@
rth->u.dst.lastuse = jiffies;
dst_hold(&rth->u.dst);
rth->u.dst.__use++;
- rt_cache_stat[smp_processor_id()].in_hit++;
+ RT_CACHE_STAT_INC(in_hit);
read_unlock(&rt_hash_table[hash].lock);
skb->dst = (struct dst_entry*)rth;
return 0;
@@ -2046,7 +2048,7 @@
rth->u.dst.output=ip_output;
- rt_cache_stat[smp_processor_id()].out_slow_tot++;
+ RT_CACHE_STAT_INC(out_slow_tot);
if (flags & RTCF_LOCAL) {
rth->u.dst.input = ip_local_deliver;
@@ -2056,7 +2058,7 @@
rth->rt_spec_dst = fl.fl4_src;
if (flags & RTCF_LOCAL && !(dev_out->flags & IFF_LOOPBACK)) {
rth->u.dst.output = ip_mc_output;
- rt_cache_stat[smp_processor_id()].out_slow_mc++;
+ RT_CACHE_STAT_INC(out_slow_mc);
}
#ifdef CONFIG_IP_MROUTE
if (res.type == RTN_MULTICAST) {
@@ -2114,7 +2116,7 @@
rth->u.dst.lastuse = jiffies;
dst_hold(&rth->u.dst);
rth->u.dst.__use++;
- rt_cache_stat[smp_processor_id()].out_hit++;
+ RT_CACHE_STAT_INC(out_hit);
read_unlock_bh(&rt_hash_table[hash].lock);
*rp = rth;
return 0;
@@ -2634,6 +2636,11 @@
ipv4_dst_ops.gc_thresh = (rt_hash_mask + 1);
ip_rt_max_size = (rt_hash_mask + 1) * 16;
+ rt_cache_stat = kmalloc_percpu(sizeof (struct rt_cache_stat),
+ GFP_KERNEL);
+ if (!rt_cache_stat)
+ goto out_enomem1;
+
devinet_init();
ip_fib_init();
@@ -2659,6 +2666,8 @@
out:
return rc;
out_enomem:
+ kfree_percpu(rt_cache_stat);
+out_enomem1:
rc = -ENOMEM;
goto out;
}
^ permalink raw reply
* Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Maciej W. Rozycki @ 2002-12-16 13:44 UTC (permalink / raw)
To: Jun Sun, Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20021214051851.A3756@linux-mips.org>
On Sat, 14 Dec 2002, Ralf Baechle wrote:
> > OCW3 defaults to IRR in our setup (as it does for the chip itself after
> > writing ICWs) -- you need to select ISR explicitly before reading and
> > reset it afterwards to avoid surprises. Unless we change the default for
> > MIPS, which seems feasible -- we don't have to handle i386 oddities like
> > I/O APICs and weird chipset bugs. And we avoid the need to grab a
> > spinlock here. Alpha went this path.
>
> We don't have I/O APICs but there's a bunch of MIPS boxes that are based
> on Intel chipsets plus glue logic so we may have to deal with some of the
> same kind of bugs. And I'd not be surprised if the 8259 VHDL are coming
> from the same source as the x86 ones so because I didn't want to tickle
> the dragon's tail so I simply recycled the x86 code. Overly defensive?
> Probably.
Definitely -- the only place the IRR is used is the Neptune (i82378IB/ZB
SIO, i82379AB SIO.A or i82374EB/SB ESC; one or more of them -- the note in
arch/i386/kernel/time.c isn't detailed enough) i8254 core latch
malfunction workaround. This is needed for do_slow_gettimeoffset(), which
we do not need as we use the processor's internal timer for getting the
offset (or are there any R3k-class systems with an Intel-style chipset?).
Even if we needed do_slow_gettimeoffset(), I don't think anyone uses any
of these chips in a MIPS system (please correct me if I'm wrong) and the
workaround isn't implemented.
Some Alphas do actually use the i82378ZB SIO component, but they use a
processor's internal timer, too so they don't use do_slow_gettimeoffset()
and don't implement the workaround either.
Surprisingly, there are no known i8259 core implementation bugs.
BTW, the workaround probably need not use the IRR -- the Read-Back i8254
command can be used to get the output state. It's even possible with the
read-back command the latch for the counter would work correctly, so no
workaround would be needed at all. The code is ancient, though, and
changing it would be tough -- a tester with a buggy system would be
needed.
> > > + atomic_inc(&irq_err_count);
> > > + } else {
> > > + do_IRQ(irq,regs);
> >
> > And how about using an offset passed from a user? We're not on a PC --
> > i8259 IRQs do not have to start from 0. E.g. I find cleaner allocating
> > CPU IRQs first if handled.
>
> There's still ISA drivers out there with hard coded interrupt numbers.
> That's why we assume that ISA / i8259 interrupts are 0 ... 15. Doesn't
> legacy stuff suck ...
Ah, I see.
BTW, I thought on the code a bit and I discovered a few potential
problems due to races. Handling them depends on the way acks are sent to
i8259s -- Jun, could you please elaborate?
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: /proc/cpuinfo and hyperthreading
From: Brian Jackson @ 2002-12-16 13:54 UTC (permalink / raw)
To: Scott Robert Ladd; +Cc: Linux Kernel Mailing List
In-Reply-To: <FKEAJLBKJCGBDJJIPJLJEEKMDLAA.scott@coyotegulch.com>
You could always boot once with nosmp and run some benchmarks and then
reboot (with smp) and run some more benchmarks, and see if there is a
difference.
--Brian Jackson
Scott Robert Ladd writes:
> Zwane Mwaikambo wrote:
>> It's ok.
>
> I'm not so sure.
>
> To get the most benefit from two logical CPUs, don't I need the kernel to
> operate as a 2-CPU SMP system?
>
> Windows XP initializes the system as SMP with two CPUs; when I run an OpenMP
> application under Windows, it reports two CPUs and a maximum of two threads.
> Under Linux,
>
> Linux SMP should initialize based on the number of logical CPUS, not the
> physical number of ships; thus, I should be seeing two CPUs in
> /proc/cpuinfo, not one.
>
> ..Scott
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Linux v2.5.52
From: Gerd Knorr @ 2002-12-16 13:53 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212151930120.12906-100000@penguin.transmeta.com>
Linus Torvalds <torvalds@transmeta.com> writes:
> XFS, JFS, ACPI and USB updates. KConfig update, and Rusty's module
> parameter implementation. And fix the stupid nanosleep() thing that broke
> some programs.
Something broke the init= kernel cmd line option, I suspect Rusty's
parameter stuff ...
I boot my box via initrd + pivot_root, with "ramdisk_size=16384
root=/dev/ram0 init=/linuxrc rw" on the kernel command line. When
booting 2.5.52 I get a shell prompt at the point where usually linxrc
starts. Just typing "exec /linuxrc" at this point invokes the usual
boot sequence ...
Gerd
--
Weil die späten Diskussionen nicht mal mehr den Rotwein lohnen.
-- Wacholder in "Melanie"
^ permalink raw reply
* Re: IDE-CD and VT8235 issue!!!
From: Patrick Petermair @ 2002-12-16 13:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Vojtech Pavlik
In-Reply-To: <20021216113458.A31837@ucw.cz>
Vojtech Pavlik:
> If you can, please try 2.4.20 with this patch.
Wow, that was fast.
The patch works perfect. The kernel boots with no problem, I have dma on
all my disk AND I can mount a CD/DVD without any problems.
Would be cool to see this patch included in the 2.4.21 kernel.
Thanks,
Patrick
^ permalink raw reply
* labelling partitions with reiserfstune
From: Nick Burrett @ 2002-12-16 13:31 UTC (permalink / raw)
To: reiserfs-list
Hi,
It would be useful if the disk label of a mounted partition could be
changed by reiserfstune. Since I'm only after changing the label and
not the journal, the following assertion seems unreasonable.
bash-2.05# reiserfstune -l / /dev/rd/c0d0p1
<-------------reiserfstune, 2002------------->
reiserfsprogs 3.6.4
reiserfstune: can not rebuild journal of mounted filesystem
bash-2.05#
Regards,
Nick.
--
Nick Burrett
Network Engineer, Designer Servers Ltd. http://www.dsvr.co.uk
^ permalink raw reply
* re: /proc/cpuinfo and hyperthreading
From: Scott Robert Ladd @ 2002-12-16 13:38 UTC (permalink / raw)
To: Zwane Mwaikambo; +Cc: Robert Love, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.50.0212160133300.12535-100000@montezuma.mastecende.com>
Zwane Mwaikambo wrote:
> It's ok.
I'm not so sure.
To get the most benefit from two logical CPUs, don't I need the kernel to
operate as a 2-CPU SMP system?
Windows XP initializes the system as SMP with two CPUs; when I run an OpenMP
application under Windows, it reports two CPUs and a maximum of two threads.
Under Linux,
Linux SMP should initialize based on the number of logical CPUS, not the
physical number of ships; thus, I should be seeing two CPUs in
/proc/cpuinfo, not one.
..Scott
^ permalink raw reply
* Re: rmap and nvidia?
From: Ducrot Bruno @ 2002-12-16 13:32 UTC (permalink / raw)
To: Eyal Lebedinsky; +Cc: Linux Kernel
In-Reply-To: <3DFBDDA0.CD0B55BA@eyal.emu.id.au>
On Sun, Dec 15, 2002 at 12:40:48PM +1100, Eyal Lebedinsky wrote:
> Philip Dodd wrote:
> >
> > Eyal Lebedinsky wrote:
> > 8<
> > > The replies for people in the know (Rik, wli) give a clue but not an
> > > answer. Use mere mortals want a proper patch in order to build and
> > > use this kernel.
> >
> > This driver, you mean ;-)
>
> Well, yes and no. This kernel is of no use to me without this driver
> right now.
>
Ah, OK. You need to play quake3 with this kernel, I guess.
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page
^ permalink raw reply
* bug in doc drivers?
From: the muppeteer @ 2002-12-16 13:52 UTC (permalink / raw)
To: linux-mtd
Hello,
I compile my kernel (2.4.20) with mtd support.
I did everything as said in the documentation mtd-jffs-HOWTO.
I boot with my new kernel, and my flash is detected.
I mount my flash.
I write a large amount of data on it ,so that its 100% full.
Then, when I do a sync, the system freezes for about 1min 30.
Why ? Is this a bug in the drivers ? Does the flash need swap to
function properly now ? it didn't need swap before with the binairy
old modules.
System:
-------
Red Hat 7.2
Kernel 2.4.20
No swap (its for a bootable cd)
DiskOnChip 2000 16MB
Regards,
themuppeteer.
_________________________________________________________________
Ontvang je Hotmail & Messenger berichten op je mobiele telefoon met Hotmail
SMS http://www.msn.nl/jumppage/
^ permalink raw reply
* NFS crash with 2.4.19
From: Stian Jordet @ 2002-12-16 13:29 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 626 bytes --]
I got this error on my server tonight. It is running 2.4.19, and have
done so happily without reboot a couple of months. Last night I
nfs-mounted a disk from another box on the server. This other box
crashed during the night (probably some hardware fault), but then I got
the attached error message in the log. The server still worked fine for
remote services, but I got no response at all on the console.
Anyone have any idea why? I just took a controlled reboot to get rid of
it as fast as possible, because I'm not around the server more for a
couple of days. But what could have caused this?
Best regards,
Stian Jordet
[-- Attachment #2: crash.txt --]
[-- Type: text/plain, Size: 2173 bytes --]
Dec 16 03:51:12 dodge kernel: Unable to handle kernel NULL pointer dereference at virtual address 000005dc
Dec 16 03:51:12 dodge kernel: printing eip:
Dec 16 03:51:12 dodge kernel: 000005dc
Dec 16 03:51:12 dodge kernel: *pde = 00000000
Dec 16 03:51:12 dodge kernel: Oops: 0000
Dec 16 03:51:12 dodge kernel: CPU: 0
Dec 16 03:51:12 dodge kernel: EIP: 0010:[cleanup+1212/-1072693536] Not tainted
Dec 16 03:51:12 dodge kernel: EFLAGS: 00010296
Dec 16 03:51:12 dodge kernel: eax: c4ba53a0 ebx: cb311a60 ecx: c74f19a0 edx: 0000069c
Dec 16 03:51:12 dodge kernel: esi: c33f00e0 edi: 00000040 ebp: 00000000 esp: c2e37bb4
Dec 16 03:51:12 dodge kernel: ds: 0018 es: 0018 ss: 0018
Dec 16 03:51:12 dodge kernel: Process wget (pid: 19813, stackpage=c2e37000)
Dec 16 03:51:12 dodge kernel: Stack: c8ba2024 c01f1250 cb311a60 000005fb 00000000 00000040 c2e37c34 c8ba2024
Dec 16 03:51:12 dodge kernel: c02038a3 cb311a60 000005fb 00000040 c2e37c34 c021b568 cb311a60 c2e37cd0
Dec 16 03:51:12 dodge kernel: 00002098 00000000 000005c8 00000040 000005c8 c2e37c34 c8ba2010 00000040
Dec 16 03:51:12 dodge kernel: Call Trace: [sock_alloc_send_skb+28/36] [ip_build_xmit_slow+419/1216] [udp_getfrag+0/196] [ip_build_xmit+78/840] [udp_getfrag+0/196]
Dec 16 03:51:12 dodge kernel: [qdisc_restart+19/200] [udp_sendmsg+849/972] [udp_getfrag+0/196] [inet_sendmsg+58/64] [sock_sendmsg+105/136] [do_xprt_transmit+334/988]
Dec 16 03:51:12 dodge kernel: [nf_hook_slow+238/324] [ip_output+278/284] [ip_finish_output2+0/208] [ip_queue_xmit2+286/512] [nfs_xdr_writeargs+0/216] [rpcauth_marshcred+85/92]
Dec 16 03:51:12 dodge kernel: [xprt_transmit+158/168] [call_transmit+62/100] [__rpc_execute+168/700] [nfs_write_rpcsetup+113/332] [rpc_call_setup+50/112] [rpc_execute+87/112]
Dec 16 03:51:12 dodge kernel: [nfs_flush_one+461/728] [nfs_flush_list+88/368] [nfs_flush_file+86/116] [nfs_strategy+66/72] [nfs_updatepage+388/512] [nfs_commit_write+28/36]
Dec 16 03:51:12 dodge kernel: [generic_file_write+1251/1800] [nfs_file_write+159/172] [sys_write+150/240] [system_call+51/56]
Dec 16 03:51:12 dodge kernel:
Dec 16 03:51:12 dodge kernel: Code: Bad EIP value.
^ 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.