* access memory mapped registers
From: Muaddi, Cecilia @ 2003-01-09 22:00 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
This is probably one of those silly questions again, and I seem to be having
a lot of them lately.
I will like to access some memory mapped registers through user space
applications.
Do i just use the "mmap" function calls to map the physical memory to my
user space?
My BR/OR registers are set up properly to handle the addresses, but do i
need to configure
the kernel for those memory regions?
The address I am looking at is at physical location 0x60000000 and
0x40000000. My RAM space is mapped to
virtual address starting at 0xc0000000 (where the RAM's physical address is
from 0x0 - 0x00ffffff)
THank you very much for your help
Cecilia
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: NFS as a Cluster File System.
From: Brian Jackson @ 2003-01-09 22:04 UTC (permalink / raw)
To: nfs, linux-ha
In-Reply-To: <3E1DE570.7070207@emageon.com>
On Thursday 09 January 2003 03:11 pm, Brian Tinsley wrote:
> Lorn Kay wrote:
> > Is NFS a viable CFS? (I'm cross posting this due to a discussion on
> > the the linux-ha list recently.)
>
> Since there is not a really good cluster filesystem for Linux that is
> not either "half baked"
Hey, we're working on it ;)
--Brian Jackson
OpenGFS Project
> (IMHO - I'm probably going to get smacked over
> that statement!) or cost an arm and a leg, this is exactly the route we
> have taken.
>
> > The NFS server is a high-quality dedicated machine (Net App, EMC,
> > etc.)
>
> We've had great success with just using SMP Linux servers. We do have
> one EMC IP4700 in production, and it's a nice system, but I prefer the
> Linux based alternative.
>
> > Linux clients can use TCP instead of UDP.
>
> Although I haven't had problems with this in our lab, I believe the NFS
> authors still consider this experimental.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [2.5] IRQ distribution in the 2.5.52 kernel
From: Andrew Theurer @ 2003-01-09 22:08 UTC (permalink / raw)
To: Kamble, Nitin A, linux-kernel, mbligh
Cc: Saxena, Sunil, Mallick, Asit K, Nakajima, Jun
In-Reply-To: <E88224AA79D2744187E7854CA8D9131DA5CE59@fmsmsx407.fm.intel.com>
<snip>
> > test again with/without HT.
> >
> > Here are the results:
> >
> > 4P, no HT, 1 x e1000, no kirq: 1214 Mbps, 4% idle
> > 4P, no HT, 1 x e1000, kirq: 1223 Mbps, 4% idle,
>
> +0.74%
> [NK] It is surprising to see single e1000 is giving bandwidth more than
> 1Gbps. What can be the reason for this extra bandwidth? ... Maybe
> compression is happening somewhere.
Full duplex. I suppose theoretical full throughput is 2Gbps. Sar reported
about 1174 Mb/sec with one adapter on one of these results above, and it was
454 Recv/720 Tx (I had the percentages incorrectly swapped in previous
email). This is still with an MTU of 1500!
> > I suppose we didn't see much of an improvement here because we never
>
> >
> > 4P, HT, 1 x e1000, no kirq: 1214 Mbps, 25% idle
> > 4P, HT, 1 x e1000, kirq: 1220 Mbps, 30% idle,
>
>
> >
> > 4P, HT, 2 x e1000, no kirq: 1269 Mbps, 23% idle
> > 4P, HT, 2 x e1000, kirq: 1329 Mbps, 18% idle
>
> +4.7%
> [NK] It can be a case that throughput is getting limited by the network
> infrastructure or total load of clients. If we know the theoretical
> desired maximum throughput then we will get a better idea about the
> bottleneck. It would be interesting to see the results, after adding one
> more e1000 card to the server.
It occurred to me later, the answer was obvious, the one you mentioned:
clients. I originally had enough clients to accomplish 1000 Mbps, but I'm
pretty sure 44 client will not cut it for NetBench at around 1500 Mbps (where
this hopefully will end up). NetBench throttles the clients, so I really
can't drive them much harder. There is an option to simulate more than one
client per computer, but I have had trouble in the past with that, but I am
going to give it one more try.
>
> > OK, almost 5% better!
>
> [NK] It's a pretty good number!
^ permalink raw reply
* Re: [patch 2.5] 2-pass PCI probing, generic part
From: Ivan Kokshaysky @ 2003-01-09 22:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Ivan Kokshaysky, Linus Torvalds, Alan Cox, Grant Grundler,
Paul Mackerras, Eric W. Biederman, davidm,
Linux Kernel Mailing List, greg
In-Reply-To: <1042134735.522.19.camel@zion.wanadoo.fr>
On Thu, Jan 09, 2003 at 06:52:15PM +0100, Benjamin Herrenschmidt wrote:
> Yes, On these, I'll skip the pci<->pci bridge in cases there is one on
> the path too, this will add some nasty logic to the pmac pci code, but
> that's ok as long as that crap doesn't leak out of
> arch/ppc/platforms/pmac_*
I don't see why it would add any extra logic to your pci code. You only
need to implement simple pmac-specific "FIXUP_EARLY" routine for I/O ASIC.
Something like this:
static void __init fixup_io_asic(struct pci_dev *asic)
{
struct pci_dev *bridge;
/* Set up asic->resource[] (using firmware info?) */
...
asic->skip_probe = 1;
/* Also, don't probe parent bridge */
bridge = asic->bus->self;
if (bridge && (bridge->class >> 8) == PCI_CLASS_BRIDGE_PCI)
bridge->skip_probe = 1;
}
And you've done with it.
Note that in most cases PCI-PCI bridges can be safely excluded from
pci_read_bases() simply because they have neither regular BARs nor
ROM BAR (even though PCI spec allows that).
Ivan.
^ permalink raw reply
* Re: ipv6 stack seems to forget to send ACKs
From: Mika Liljeberg @ 2003-01-09 22:12 UTC (permalink / raw)
To: Wichert Akkerman; +Cc: linux-kernel, Maciej Soltysiak, netdev
In-Reply-To: <20030108170139.GL22951@wiggy.net>
Hi Wichert,
Looking at your trace it seems that the receiving machine is dropping
all packets that do not have traffic class set. Note that all segments
received with [class 0x2] get properly acked. The others probably don't
get to TCP at all. You might want to check your filters and QoS
policies.
BR,
MikaL
On Wed, 2003-01-08 at 19:01, Wichert Akkerman wrote:
> Previously Maciej Soltysiak wrote:
> > I seem to be getting better results than you, i think that it is not an
> > issue of ipv6 implementation but simply the case of time sensitive
> > traffic fighting with other Internet traffic over tunnels through ipv4
> > networks.
>
> Actually, I don't follow this. How could any kind of traffic shaping
> result in my client not sending ACKs, which is what the tcpdump
> seems to indicate? I can understand packets being dropped which
> would result in retransmits, but that is not the case here.
>
> Wichert.
>
> (usual I'm-no-network-guru-and-might-be-misreading-things disclaimer here)
^ permalink raw reply
* [2.5.55] [PATCH] AGP: missing includes on Alpha
From: Falk Hueffner @ 2003-01-09 22:12 UTC (permalink / raw)
To: linux-kernel; +Cc: davej, Bjorn Helgaas, Ivan Kokshaysky
[-- Attachment #1: Type: text/plain, Size: 191 bytes --]
Hi,
the following patch, which only adds some includes, is needed to
compile AGP support on Alpha. After that, it works fine with my AMD
Irongate chipset and a Radeon 7500 card.
--
Falk
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: alpga-agp-includes.patch --]
[-- Type: text/x-patch, Size: 2007 bytes --]
diff -Nurp linux-2.5.55/drivers/char/agp/amd-k7-agp.c linux-2.5.55.hacked/drivers/char/agp/amd-k7-agp.c
--- linux-2.5.55/drivers/char/agp/amd-k7-agp.c 2003-01-09 05:04:28.000000000 +0100
+++ linux-2.5.55.hacked/drivers/char/agp/amd-k7-agp.c 2003-01-09 22:45:37.000000000 +0100
@@ -6,6 +6,10 @@
#include <linux/pci.h>
#include <linux/init.h>
#include <linux/agp_backend.h>
+#include <linux/gfp.h>
+#include <linux/page-flags.h>
+#include <linux/mm.h>
+#include <asm/io.h>
#include "agp.h"
static int agp_try_unsupported __initdata = 0;
diff -Nurp linux-2.5.55/drivers/char/agp/backend.c linux-2.5.55.hacked/drivers/char/agp/backend.c
--- linux-2.5.55/drivers/char/agp/backend.c 2003-01-09 05:04:19.000000000 +0100
+++ linux-2.5.55.hacked/drivers/char/agp/backend.c 2003-01-09 22:48:16.000000000 +0100
@@ -34,6 +34,8 @@
#include <linux/miscdevice.h>
#include <linux/pm.h>
#include <linux/agp_backend.h>
+#include <linux/vmalloc.h>
+#include <asm/io.h>
#include "agp.h"
/* Due to XFree86 brain-damage, we can't go to 1.0 until they
diff -Nurp linux-2.5.55/drivers/char/agp/frontend.c linux-2.5.55.hacked/drivers/char/agp/frontend.c
--- linux-2.5.55/drivers/char/agp/frontend.c 2003-01-09 05:03:55.000000000 +0100
+++ linux-2.5.55.hacked/drivers/char/agp/frontend.c 2003-01-09 22:40:36.000000000 +0100
@@ -34,7 +34,10 @@
#include <linux/miscdevice.h>
#include <linux/agp_backend.h>
#include <linux/agpgart.h>
+#include <linux/slab.h>
+#include <linux/mm.h>
#include <asm/uaccess.h>
+#include <asm/pgtable.h>
#include "agp.h"
diff -Nurp linux-2.5.55/drivers/char/agp/generic.c linux-2.5.55.hacked/drivers/char/agp/generic.c
--- linux-2.5.55/drivers/char/agp/generic.c 2003-01-09 05:04:00.000000000 +0100
+++ linux-2.5.55.hacked/drivers/char/agp/generic.c 2003-01-09 22:42:20.000000000 +0100
@@ -34,6 +34,8 @@
#include <linux/miscdevice.h>
#include <linux/pm.h>
#include <linux/agp_backend.h>
+#include <linux/vmalloc.h>
+#include <asm/io.h>
#include "agp.h"
__u32 *agp_gatt_table;
^ permalink raw reply
* Re: PMS messaging program: where?
From: Tim Neu @ 2003-01-09 22:06 UTC (permalink / raw)
To: Jacques Chion, Tim Neu; +Cc: linux-hams
In-Reply-To: <Pine.LNX.4.44.0301092202550.2502-100000@cwoux.cerise.fr>
On Thu, 9 Jan 2003 22:04:19 +0100 (CET), Jacques Chion wrote
>
> Hello,
> you can find that program in ax25-utils-2.1.42.a-3 package.
> Best 73
Hmm. When I try to intstall ax25-utils on debian, it claims that ax25utils is
replaced by ax25-tools...
I _do_ have ax25-tools installed, though, but it does not have pms.
Evidently ax25-tools does not completely replace all funtionality of
ax25-utils, or the debian package folks have their wires crossed.
I will give a search for ax25-utils. Thanks for the help.
--
Open WebMail Project (http://openwebmail.org)
Debian Project (http://www.debian.org)
^ permalink raw reply
* Re: [PATCH][TRIVIAL] checksum.h header fixes for 2.4
From: Alan Cox @ 2003-01-09 23:01 UTC (permalink / raw)
To: Eric Weigle
Cc: Marcelo Tosatti, Trivial Patch Monkey, Linux Kernel Mailing List
In-Reply-To: <20030109200646.GG3329@lanl.gov>
On Thu, 2003-01-09 at 20:06, Eric Weigle wrote:
> I'm making a loadable module that will send IP packets; and need to do IP
> checksums. Unfortunately a simple #include of checksum.h fails because that
> file does not itself include the headers required to compile correctly.
> Several of the arch-specific files are this way.
Include the other files you need first. The kernel headers are not
really intended to always include everything you might want. That
rapidly becomes unmanagable
^ permalink raw reply
* Re: [Linux-fbdev-devel] Re: rotation.
From: Alan Cox @ 2003-01-09 23:03 UTC (permalink / raw)
To: James Simmons; +Cc: Helge Hafting, Sven Luther, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0301091956140.5660-100000@phoenix.infradead.org>
On Thu, 2003-01-09 at 19:59, James Simmons wrote:
> > > So, we also support fbcon for not left to righ locales ?
> > This looks like a high-level thing to me.
> > Ideally something like ansi escape sequences to switch between
> > left-to-right, right-to-left, and up-to-down advancing of
> > the cursor. Then the same multilingual apps will work with
> > fbdev, xterm, and other terminals and emulators that
> > implement those operations.
>
> Yeap. Such things are supported on the console level. ISO6429 support.
Note btw that the support ends rather abruptly on the console input side.
There is no support for 3 or 4 byte utf8 input sequences and the delete
key code in the kernel has no understanding of or support for UTF8
deletion behaviour
^ permalink raw reply
* Re: High FS Activity Crash
From: Benjamin LaHaise @ 2003-01-09 22:17 UTC (permalink / raw)
To: Adam Voigt; +Cc: linux-kernel
In-Reply-To: <1041861941.13245.26.camel@beowulf.cryptocomm.com>
On Mon, Jan 06, 2003 at 09:05:40AM -0500, Adam Voigt wrote:
> Ok, on my fileserver I'm running Redhat 7.2 with Redhat kernel 2.4.7-10
> and when I have a large number of people downloading from me at one
> time, Samba, ProFTPD, Apache, and SSH all stop responding, and I get the
> following in my log, the only thing special I could think about my setup
> is I have 3 NIC's bonded together to be load balanced on the same IP,
> any ideas?
That looks like a vm bug that was fixed around the 2.4.9-31 timeframe. You
really should be using the latest errata kernel that Red Hat has released,
as many bugs have been fixed since 2.4.7-10.
-ben
^ permalink raw reply
* RE: acpi_button misses some static's
From: Grover, Andrew @ 2003-01-09 22:10 UTC (permalink / raw)
To: Pavel Machek, Rusty trivial patch monkey Russell, kernel list
Already applied to my local tree, will be in the next ACPI patch, which
should be very soon.
> From: Pavel Machek [mailto:pavel@ucw.cz]
> This adds them, please apply.
Thanks -- Regards -- Andy
^ permalink raw reply
* Re: ipv6 stack seems to forget to send ACKs
From: Wichert Akkerman @ 2003-01-09 22:21 UTC (permalink / raw)
To: linux-kernel, netdev
In-Reply-To: <1042150352.4688.15.camel@devil>
Previously Mika Liljeberg wrote:
> Looking at your trace it seems that the receiving machine is dropping
> all packets that do not have traffic class set. Note that all segments
> received with [class 0x2] get properly acked. The others probably don't
> get to TCP at all. You might want to check your filters and QoS
> policies.
I don't have any filters and QoS support isn't even enabled in this
kernel.
Wichert.
--
Wichert Akkerman <wichert@wiggy.net> http://www.wiggy.net/
A random hacker
^ permalink raw reply
* RE: PMS messaging program: where?
From: Tim Neu @ 2003-01-09 22:14 UTC (permalink / raw)
To: linux-hams
In-Reply-To: <DCC9161CB1A3EC44A997584E5F97C5BD435B3E@rmimail.rci.local>
On Thu, 9 Jan 2003 12:49:55 -0800, Joshua Hayworth wrote
> You mean this?
>
> http://www.marex-na.org/fileshtml/packetmail.html
>
> <quote>
> Amateur Radio Packet Mail from the International Space Station Alpha
>
> The crew of the International Space Station has access to a public
> Amateur Radio email system called the "Personal Message System" (PMS)
Nope. PMS seems to be an abbreviation with many meanings. (!) In this
article, (i believe) they are referring to a personal message system in the
generic sense. At least, if they are referring to the program, they are
still no help because they do not link to a copy of it.
I was looking for a software program by that exact name. It is basically a
packet mailbox for linux.
The other response will put the issue to rest, I believe. I will check
tonight when I get home and see if the program is in the ax25-utils package.
Thanks for the help.
KC0LQL
--
Open WebMail Project (http://openwebmail.org)
Debian Project (http://www.debian.org)
^ permalink raw reply
* Re: MB without keyboard controller / USB-only keyboard ?
From: Vojtech Pavlik @ 2003-01-09 22:24 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: linux-kernel
In-Reply-To: <20030109114247.211f7072.skraw@ithnet.com>
On Thu, Jan 09, 2003 at 11:42:47AM +0100, Stephan von Krawczynski wrote:
> Hello all,
>
> how do I work with a mb that contains no keyboard controller, but has only USB
> for keyboard and mouse?
> While booting the kernel I get:
>
> pc_keyb: controller jammed (0xFF)
>
> (a lot of these :-)
>
> and afterwards I cannot use the USB keyboard.
> Everything works with a mb that contains a keyboard-controller, but where I use a
> USB keyboard.
Get 2.5. ;) It should work without a kbd controller ... you can even
disable it in the kernel config ...
--
Vojtech Pavlik
SuSE Labs
^ permalink raw reply
* ksoftirqd_CPU0 causing severe latency
From: jroland @ 2003-01-09 22:25 UTC (permalink / raw)
To: linux-kernel
I am running a RH7.2 router with kernel 2.4.18-19.7.x and upgraded from
2.4.18-17 in hopes this would fix the problem, but it hasn't.
The problem I am experiencing is that after a while, the system begins to
lag badly, and running "ps -ax" writes to a SSH console like a terminal
running at 14.4kbps. This only seems to have occurred after the box
started procesing a network load.
The box is a router, with a Supermicro (model=?) motherboard with embedded
Intel EEpro/100 NICs using the eepro100 module. This box is also serving
as an iptables filter for the network as well. It's processing
approximately 60Mbps sustained traffic outbound, and about 10-15Mbps
traffic inbound.
The box also lags SEVERLY when I'm trying to use the state matching in the
kernel (as module), lagging badly when ip_conntrack is loaded.
In contrast, I am running the same OS and kernel versions on another box
(same modules) and am not having the same problem (it is only handling
about 5Mbps sustained out, and 1Mbps sustained inbound).
I need HELP!
Here are the specs on the troubled system:
Intel P3-1.0GHz, 512MB RAM, 2x Intel EEPro/100 (eepro100 module)
Dual CPU board, w/o 2nd CPU, running non-smp kernel (uniprocessor kernel).
Module List (system runnin at its best):
Module Size Used by Not tainted
cls_route 5056 0 (unused)
cls_u32 5764 1
cls_fw 3264 0 (unused)
sch_prio 3552 0 (unused)
sch_sfq 4512 0 (unused)
sch_tbf 3264 2
sch_cbq 14080 1
autofs 11172 0 (autoclean) (unused)
eepro100 20240 2
ipt_REJECT 3744 22 (autoclean)
iptable_filter 2464 1 (autoclean)
ip_tables 13696 2 [ipt_REJECT iptable_filter]
ext3 64768 5
jbd 47892 5 [ext3]
PID TTY STAT TIME COMMAND
1 ? S 1:43 init [3]
2 ? SW 0:00 [keventd]
3 ? SW 2:17 [kapmd]
4 ? RWN 506:27 [ksoftirqd_CPU0]
5 ? SW 1:34 [kswapd]
6 ? SW 0:00 [bdflush]
7 ? SW 0:31 [kupdated]
8 ? SW 0:00 [mdrecoveryd]
12 ? SW 0:56 [kjournald]
134 ? SW 0:00 [kjournald]
135 ? SW 0:00 [kjournald]
136 ? SW 0:47 [kjournald]
137 ? SW 0:27 [kjournald]
598 ? S 0:21 syslogd -m 0
603 ? S 0:01 klogd -2
641 ? SL 7:34 ntpd -U ntp
695 ? S 0:49 /usr/sbin/snmpd -s -l /dev/null -P
/var/run/snmpd -a
713 ? S 0:07 /usr/sbin/sshd
746 ? S 0:00 xinetd -stayalive -reuse -pidfile
/var/run/xinetd.pid
787 ? S 0:15 crond
823 ? S 0:00 /usr/sbin/atd
829 ? S 0:00 /etc/bkupexec/agent.be -c
/etc/bkupexec/agent.cfg
843 ? SN 2:01 /etc/bkupexec/agent.be -c
/etc/bkupexec/agent.cfg
850 ? S 0:16 rhnsd --interval 120
891 ? S 2:24 /usr/bin/perl /usr/libexec/webmin/miniserv.pl
/etc/we
895 tty1 S 0:00 /sbin/mingetty tty1
896 tty2 S 0:00 /sbin/mingetty tty2
897 tty3 S 0:00 /sbin/mingetty tty3
898 tty4 S 0:00 /sbin/mingetty tty4
899 tty5 S 0:00 /sbin/mingetty tty5
900 tty6 S 0:00 /sbin/mingetty tty6
5409 ? S 1:42 /usr/sbin/sshd
5410 pts/0 S 0:22 -bash
5552 ? S 0:11 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5558 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5559 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5560 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5561 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5562 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5563 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5564 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5565 ? S 0:00 /usr/sbin/httpd -DHAVE_ACCESS -DHAVE_PROXY
-DHAVE_AUT
5653 pts/0 R 0:01 ps -ax
4:23pm up 1 day, 22:33, 1 user, load average: 0.66, 0.73, 0.81
43 processes: 41 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 1.3% user, 1.3% system, 0.0% nice, 20.4% idle
Mem: 513032K av, 183252K used, 329780K free, 0K shrd, 105560K
buff
Swap: 257000K av, 0K used, 257000K free 47172K
cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
5655 root 19 0 1028 1024 824 R 33.6 0.1 0:01 top
4 root 35 19 0 0 0 RWN 18.8 0.0 506:40
ksoftirqd_CPU0
641 ntp 15 0 1932 1932 1732 S 0.6 0.3 7:35 ntpd
1 root 15 0 508 508 440 S 0.0 0.0 1:43 init
2 root 15 0 0 0 0 SW 0.0 0.0 0:00 keventd
3 root 15 0 0 0 0 SW 0.0 0.0 2:17 kapmd
5 root 15 0 0 0 0 SW 0.0 0.0 1:34 kswapd
6 root 25 0 0 0 0 SW 0.0 0.0 0:00 bdflush
7 root 15 0 0 0 0 SW 0.0 0.0 0:31 kupdated
8 root 25 0 0 0 0 SW 0.0 0.0 0:00 mdrecoveryd
12 root 15 0 0 0 0 SW 0.0 0.0 0:56 kjournald
134 root 15 0 0 0 0 SW 0.0 0.0 0:00 kjournald
135 root 15 0 0 0 0 SW 0.0 0.0 0:00 kjournald
136 root 15 0 0 0 0 SW 0.0 0.0 0:47 kjournald
137 root 16 0 0 0 0 SW 0.0 0.0 0:27 kjournald
598 root 15 0 612 612 516 S 0.0 0.1 0:21 syslogd
603 root 15 0 1208 1208 448 S 0.0 0.2 0:01 klogd
695 root 16 0 2940 2940 1844 S 0.0 0.5 0:49 snmpd
^ permalink raw reply
* Re: "Mother" == "computer-illiterate"
From: Alan Cox @ 2003-01-09 23:11 UTC (permalink / raw)
To: Val Henson
Cc: Linux Kernel Mailing List, David van Hoose, dpaun, rms,
Miles Bader, lm, acahalan
In-Reply-To: <20030109194019.GH26010@boardwalk>
On Thu, 2003-01-09 at 19:40, Val Henson wrote:
> P.S. For extra credit (but no ThinkGeek certificate) you can look up
> the following women in computer science, some of whom are mothers:
> Mary Baker, Margo Seltzer, Monica Lam, Ellen Spertus, Carla Ellis, and
> Barbara Simons.
and of course Sally Floyd, and even Hedy Lamarr (bonus points for those
who know what her networking related patent is on)
^ permalink raw reply
* Re: [patch 2.5] 2-pass PCI probing, generic part
From: Benjamin Herrenschmidt @ 2003-01-09 22:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ivan Kokshaysky, Alan Cox, Grant Grundler, Paul Mackerras,
Eric W. Biederman, davidm, Linux Kernel Mailing List, greg
In-Reply-To: <Pine.LNX.4.44.0301091413520.1436-100000@penguin.transmeta.com>
On Thu, 2003-01-09 at 23:16, Linus Torvalds wrote:
> On Fri, 10 Jan 2003, Ivan Kokshaysky wrote:
> >
> > Note that in most cases PCI-PCI bridges can be safely excluded from
> > pci_read_bases() simply because they have neither regular BARs nor
> > ROM BAR (even though PCI spec allows that).
>
> This might be a good approach to take regardless - don't read pci-pci
> bridge BAR (or host-bridge BAR's for that matter), simply because
>
> (a) bridges are more "interesting" than regular devices, and disabling
> part of them might be a stupid thing.
> (b) we're generally not really interested in the end result anyway
I completely agree. For example, I have already a bunch of cases where I
have to explicitely "hide" the host bridge from linux PCI layer as those
have BARs that mustn't be touched. A typical example is the 405gp
internal PCI host. It has a BAR that represents the view of system RAM
from bus mastering PCI devices. Of course, the kernel doesn't understand
that and tries to remap it away from 0 where it belongs ;)
Ben.
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* UnitedLinux violating GPL?
From: Jeff Garzik @ 2003-01-09 22:27 UTC (permalink / raw)
To: linux-kernel
Anybody know where the source rpm for UnitedLinux kernel is?
[to be distinguished from kernel-source rpm]
AFAICS they are not distributing source code to their published kernel
binaries... which is a very obvious GPL violation.
I'm also surprised the even-more-pro-GPL-than-me people have not jumped
on UnitedLinux for not distributing source code.
Jeff, looking for useful [rumored] drivers/net patches
^ permalink raw reply
* Re: PMS messaging program: where?
From: Tomi Manninen @ 2003-01-09 22:20 UTC (permalink / raw)
To: Tim Neu; +Cc: linux-hams
In-Reply-To: <20030109220627.M32751@tneu.visi.com>
On Thu, 9 Jan 2003, Tim Neu wrote:
> On Thu, 9 Jan 2003 22:04:19 +0100 (CET), Jacques Chion wrote
> >
> > you can find that program in ax25-utils-2.1.42.a-3 package.
>
> Hmm. When I try to intstall ax25-utils on debian, it claims that ax25utils is
> replaced by ax25-tools...
A few years ago ax25-utils was split into three packages: libax25,
ax25-tools and ax25-apps. At the same time a few of the applications were
left out to be maintained separately. At least node and pms belong to that
category.
Unfortunately it seems that no one took pms and I believe there isn't any
recent versions out there... Someone correct me if I'm wrong.
You could rip pms from the old ax25-utils but it would need a bit of
tweaking to compile on a modern system.
--
Tomi Manninen Internet: oh2bns@sral.fi
OH2BNS AX.25: oh2bns@oh2rbi.fin.eu
KP20ME04 Amprnet: oh2bns@oh2rbi.ampr.org
^ permalink raw reply
* fs errors on thinkpad R31
From: Bernd Schubert @ 2003-01-09 22:20 UTC (permalink / raw)
To: ReiserFS
[-- Attachment #1: Type: text/plain, Size: 433 bytes --]
Hi,
this is the second time within 14 days after which I had to run reiserfsck on
my IBM Thinkpad R31.
This time I lost a directory with 49 files (it seems it were only kernel
modules, so probably not so important data).
I have attached the error messages from the /var/log/messages file.
System: Thinkpad R31; vanilla linux-2.4.20 + cpufreq kernel
Any ideas whats going wrong?
Thanks in advance,
Bernd
[-- Attachment #2: errors.log.gz --]
[-- Type: application/x-gzip, Size: 514 bytes --]
^ permalink raw reply
* [PATCH / RFC] osst, st, sg sysfs removes
From: Mike Anderson @ 2003-01-09 22:21 UTC (permalink / raw)
To: linux-scsi; +Cc: Matt_Domsch, wrlk, Kai.Makisara, dougg, mochel
This patch is against 2.5.55
This patch is in response to the mail I sent the other day on the use of
to_scsi_device with our sysfs bus/scsi/devices directory containing more
than struct scsi_device objects. A link to the thread is below.
http://marc.theaimsgroup.com/?l=linux-scsi&m=104198504307087&w=2
This patch is just a removal of osst, st, and sg's sysfs nodes in the
devices directory. Current I do not have a place to replicate this
capability. It was unclear if osst and st entries where being used. The
correct place for osst and st is to have a char tree like the block tree
and have a pointer from the scsi device to the char entry. I do not know
of the proper place for sg yet. While sg is a char device it cannot
follow the same model as it can be associated with a scsi device along
with another char device.
Doug, The removal of the sg :gen has broken lscsi -g I will work on an
option to get this working again.
-andmike
--
Michael Anderson
andmike@us.ibm.com
osst.c | 53 -----------------------------------------------------
osst.h | 2 --
sg.c | 35 -----------------------------------
st.c | 53 -----------------------------------------------------
st.h | 2 --
5 files changed, 145 deletions(-)
------
--- 1.37/drivers/scsi/osst.c Thu Dec 26 16:25:32 2002
+++ edited/drivers/scsi/osst.c Thu Jan 9 09:06:43 2003
@@ -5324,22 +5324,6 @@
#endif
-/* Driverfs file support */
-static ssize_t osst_device_kdev_read(struct device *driverfs_dev, char *page, size_t count, loff_t off)
-{
- kdev_t kdev;
- kdev.value=(int)(long)driverfs_dev->driver_data;
- return off ? 0 : sprintf(page, "%x\n",kdev.value);
-}
-static DEVICE_ATTR(kdev,S_IRUGO,osst_device_kdev_read,NULL);
-
-static ssize_t osst_device_type_read(struct device *driverfs_dev, char *page, size_t count, loff_t off)
-{
- return off ? 0 : sprintf (page, "CHR\n");
-}
-static DEVICE_ATTR(type,S_IRUGO,osst_device_type_read,NULL);
-
-
static struct file_operations osst_fops = {
.owner = THIS_MODULE,
.read = osst_read,
@@ -5529,18 +5513,6 @@
/* Rewind entry */
sprintf (name, "ot%s", formats[mode]);
- sprintf(tpnt->driverfs_dev_r[mode].bus_id, "%s:%s",
- SDp->sdev_driverfs_dev.bus_id, name);
- sprintf(tpnt->driverfs_dev_r[mode].name, "%s%s",
- SDp->sdev_driverfs_dev.name, name);
- tpnt->driverfs_dev_r[mode].parent = &SDp->sdev_driverfs_dev;
- tpnt->driverfs_dev_r[mode].bus = SDp->sdev_driverfs_dev.bus;
- tpnt->driverfs_dev_r[mode].driver_data =
- (void *)(long)__mkdev(OSST_MAJOR, dev_num + (mode << 5));
- device_register(&tpnt->driverfs_dev_r[mode]);
- device_create_file(&tpnt->driverfs_dev_r[mode],
- &dev_attr_type);
- device_create_file(&tpnt->driverfs_dev_r[mode], &dev_attr_kdev);
tpnt->de_r[mode] =
devfs_register (SDp->de, name, DEVFS_FL_DEFAULT,
OSST_MAJOR, dev_num + (mode << 5),
@@ -5548,19 +5520,6 @@
&osst_fops, NULL);
/* No-rewind entry */
sprintf (name, "ot%sn", formats[mode]);
- sprintf(tpnt->driverfs_dev_n[mode].bus_id, "%s:%s",
- SDp->sdev_driverfs_dev.bus_id, name);
- sprintf(tpnt->driverfs_dev_n[mode].name, "%s%s",
- SDp->sdev_driverfs_dev.name, name);
- tpnt->driverfs_dev_n[mode].parent= &SDp->sdev_driverfs_dev;
- tpnt->driverfs_dev_n[mode].bus = SDp->sdev_driverfs_dev.bus;
- tpnt->driverfs_dev_n[mode].driver_data =
- (void *)(long)__mkdev(OSST_MAJOR, dev_num + (mode << 5) + 128);
- device_register(&tpnt->driverfs_dev_n[mode]);
- device_create_file(&tpnt->driverfs_dev_n[mode],
- &dev_attr_type);
- device_create_file(&tpnt->driverfs_dev_n[mode],
- &dev_attr_kdev);
tpnt->de_n[mode] =
devfs_register (SDp->de, name, DEVFS_FL_DEFAULT,
OSST_MAJOR, dev_num + (mode << 5) + 128,
@@ -5606,18 +5565,6 @@
scsi_slave_detach(SDp);
osst_nr_dev--;
write_unlock(&os_scsi_tapes_lock);
- for (mode = 0; mode < ST_NBR_MODES; ++mode) {
- device_remove_file(&tpnt->driverfs_dev_r[mode],
- &dev_attr_type);
- device_remove_file(&tpnt->driverfs_dev_r[mode],
- &dev_attr_kdev);
- device_unregister(&tpnt->driverfs_dev_r[mode]);
- device_remove_file(&tpnt->driverfs_dev_n[mode],
- &dev_attr_type);
- device_remove_file(&tpnt->driverfs_dev_n[mode],
- &dev_attr_kdev);
- device_unregister(&tpnt->driverfs_dev_n[mode]);
- }
if (tpnt->header_cache != NULL) vfree(tpnt->header_cache);
if (tpnt->buffer) {
normalize_buffer(tpnt->buffer);
--- 1.8/drivers/scsi/osst.h Sat Nov 23 10:53:29 2002
+++ edited/drivers/scsi/osst.h Thu Jan 9 09:06:43 2003
@@ -559,8 +559,6 @@
int current_mode;
devfs_handle_t de_r[ST_NBR_MODES]; /* Rewind entries */
devfs_handle_t de_n[ST_NBR_MODES]; /* No-rewind entries */
- struct device driverfs_dev_r[ST_NBR_MODES];
- struct device driverfs_dev_n[ST_NBR_MODES];
/* Status variables */
int partition;
--- 1.44/drivers/scsi/sg.c Fri Dec 20 18:00:00 2002
+++ edited/drivers/scsi/sg.c Thu Jan 9 09:06:43 2003
@@ -187,7 +187,6 @@
volatile char detached; /* 0->attached, 1->detached pending removal */
volatile char exclude; /* opened for exclusive access */
char sgdebug; /* 0->off, 1->sense, 9->dump dev, 10-> all devs */
- struct device sg_driverfs_dev;
struct gendisk *disk;
} Sg_device;
@@ -1348,26 +1347,6 @@
__setup("sg_def_reserved_size=", sg_def_reserved_size_setup);
#endif
-/* Driverfs file support */
-static ssize_t
-sg_device_kdev_read(struct device *driverfs_dev, char *page,
- size_t count, loff_t off)
-{
- Sg_device *sdp = list_entry(driverfs_dev, Sg_device, sg_driverfs_dev);
- return off ? 0 : sprintf(page, "%x\n", MKDEV(sdp->disk->major,
- sdp->disk->first_minor));
-}
-static DEVICE_ATTR(kdev,S_IRUGO,sg_device_kdev_read,NULL);
-
-static ssize_t
-sg_device_type_read(struct device *driverfs_dev, char *page,
- size_t count, loff_t off)
-{
- return off ? 0 : sprintf(page, "CHR\n");
-}
-
-static DEVICE_ATTR(type,S_IRUGO,sg_device_type_read,NULL);
-
static int
sg_attach(Scsi_Device * scsidp)
{
@@ -1456,21 +1435,10 @@
sdp->detached = 0;
sdp->sg_tablesize = scsidp->host ? scsidp->host->sg_tablesize : 0;
- memset(&sdp->sg_driverfs_dev, 0, sizeof (struct device));
- sprintf(sdp->sg_driverfs_dev.bus_id, "%s:gen",
- scsidp->sdev_driverfs_dev.bus_id);
- sprintf(sdp->sg_driverfs_dev.name, "%sgeneric",
- scsidp->sdev_driverfs_dev.name);
- sdp->sg_driverfs_dev.parent = &scsidp->sdev_driverfs_dev;
- sdp->sg_driverfs_dev.bus = scsidp->sdev_driverfs_dev.bus;
-
sg_nr_dev++;
sg_dev_arr[k] = sdp;
write_unlock_irqrestore(&sg_dev_arr_lock, iflags);
- device_register(&sdp->sg_driverfs_dev);
- device_create_file(&sdp->sg_driverfs_dev, &dev_attr_type);
- device_create_file(&sdp->sg_driverfs_dev, &dev_attr_kdev);
sdp->de = devfs_register(scsidp->de, "generic", DEVFS_FL_DEFAULT,
SCSI_GENERIC_MAJOR, k,
S_IFCHR | S_IRUSR | S_IWUSR | S_IRGRP,
@@ -1553,9 +1521,6 @@
if (sdp) {
devfs_unregister(sdp->de);
sdp->de = NULL;
- device_remove_file(&sdp->sg_driverfs_dev, &dev_attr_type);
- device_remove_file(&sdp->sg_driverfs_dev, &dev_attr_kdev);
- device_unregister(&sdp->sg_driverfs_dev);
put_disk(sdp->disk);
sdp->disk = NULL;
if (NULL == sdp->headfp)
--- 1.52/drivers/scsi/st.c Sat Dec 21 08:53:05 2002
+++ edited/drivers/scsi/st.c Thu Jan 9 09:06:43 2003
@@ -3614,24 +3614,6 @@
#endif
-/* Driverfs file support */
-static ssize_t st_device_kdev_read(struct device *driverfs_dev,
- char *page, size_t count, loff_t off)
-{
- kdev_t kdev;
- kdev.value=(int)(long)driverfs_dev->driver_data;
- return off ? 0 : sprintf(page, "%x\n",kdev.value);
-}
-static DEVICE_ATTR(kdev,S_IRUGO,st_device_kdev_read,NULL);
-
-static ssize_t st_device_type_read(struct device *driverfs_dev,
- char *page, size_t count, loff_t off)
-{
- return off ? 0 : sprintf (page, "CHR\n");
-}
-static DEVICE_ATTR(type,S_IRUGO,st_device_type_read,NULL);
-
-
static struct file_operations st_fops =
{
.owner = THIS_MODULE,
@@ -3810,18 +3792,6 @@
/* Rewind entry */
sprintf (name, "mt%s", formats[mode]);
- sprintf(tpnt->driverfs_dev_r[mode].bus_id, "%s:%s",
- SDp->sdev_driverfs_dev.bus_id, name);
- sprintf(tpnt->driverfs_dev_r[mode].name, "%s%s",
- SDp->sdev_driverfs_dev.name, name);
- tpnt->driverfs_dev_r[mode].parent = &SDp->sdev_driverfs_dev;
- tpnt->driverfs_dev_r[mode].bus = SDp->sdev_driverfs_dev.bus;
- tpnt->driverfs_dev_r[mode].driver_data =
- (void *)(long)__mkdev(SCSI_TAPE_MAJOR, dev_num + (mode << 5));
- device_register(&tpnt->driverfs_dev_r[mode]);
- device_create_file(&tpnt->driverfs_dev_r[mode],
- &dev_attr_type);
- device_create_file(&tpnt->driverfs_dev_r[mode], &dev_attr_kdev);
tpnt->de_r[mode] =
devfs_register (SDp->de, name, DEVFS_FL_DEFAULT,
SCSI_TAPE_MAJOR, dev_num + (mode << 5),
@@ -3829,19 +3799,6 @@
&st_fops, NULL);
/* No-rewind entry */
sprintf (name, "mt%sn", formats[mode]);
- sprintf(tpnt->driverfs_dev_n[mode].bus_id, "%s:%s",
- SDp->sdev_driverfs_dev.bus_id, name);
- sprintf(tpnt->driverfs_dev_n[mode].name, "%s%s",
- SDp->sdev_driverfs_dev.name, name);
- tpnt->driverfs_dev_n[mode].parent= &SDp->sdev_driverfs_dev;
- tpnt->driverfs_dev_n[mode].bus = SDp->sdev_driverfs_dev.bus;
- tpnt->driverfs_dev_n[mode].driver_data =
- (void *)(long)__mkdev(SCSI_TAPE_MAJOR, dev_num + (mode << 5) + 128);
- device_register(&tpnt->driverfs_dev_n[mode]);
- device_create_file(&tpnt->driverfs_dev_n[mode],
- &dev_attr_type);
- device_create_file(&tpnt->driverfs_dev_n[mode],
- &dev_attr_kdev);
tpnt->de_n[mode] =
devfs_register (SDp->de, name, DEVFS_FL_DEFAULT,
SCSI_TAPE_MAJOR, dev_num + (mode << 5) + 128,
@@ -3885,16 +3842,6 @@
tpnt->de_r[mode] = NULL;
devfs_unregister (tpnt->de_n[mode]);
tpnt->de_n[mode] = NULL;
- device_remove_file(&tpnt->driverfs_dev_r[mode],
- &dev_attr_type);
- device_remove_file(&tpnt->driverfs_dev_r[mode],
- &dev_attr_kdev);
- device_unregister(&tpnt->driverfs_dev_r[mode]);
- device_remove_file(&tpnt->driverfs_dev_n[mode],
- &dev_attr_type);
- device_remove_file(&tpnt->driverfs_dev_n[mode],
- &dev_attr_kdev);
- device_unregister(&tpnt->driverfs_dev_n[mode]);
}
tpnt->device = NULL;
--- 1.11/drivers/scsi/st.h Fri Nov 1 04:28:10 2002
+++ edited/drivers/scsi/st.h Thu Jan 9 09:06:43 2003
@@ -107,8 +107,6 @@
int current_mode;
devfs_handle_t de_r[ST_NBR_MODES]; /* Rewind entries */
devfs_handle_t de_n[ST_NBR_MODES]; /* No-rewind entries */
- struct device driverfs_dev_r[ST_NBR_MODES];
- struct device driverfs_dev_n[ST_NBR_MODES];
/* Status variables */
int partition;
^ permalink raw reply
* RE: detecting hyperthreading in linux 2.4.19
From: Kamble, Nitin A @ 2003-01-09 22:29 UTC (permalink / raw)
To: lunz, jamesclv, linux-kernel
Cc: Nakajima, Jun, Saxena, Sunil, Mallick, Asit K, Schlobohm, Bruce
Hi James,
I have posted a patch for this on LKML. Please have look at:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0301.0/1886.html
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0301.0/1887.html
It should solve the problem you are trying to solve.
Nitin
> -----Original Message-----
> From: Jason Lunz [mailto:lunz@falooley.org]
> Sent: Thursday, January 09, 2003 1:57 PM
> To: linux-kernel@vger.kernel.org
> Subject: Re: detecting hyperthreading in linux 2.4.19
>
> jamesclv@us.ibm.com said:
> > I don't know of any way to do this in userland. The whole point is
> > that the sibling processors are supposed to look like real ones.
>
> That's unfortunately not always true. I'm writing a program that will
> run on a system that will be doing high-load routing. Testing has
shown
> that we get better performance when binding each NIC's interrupts to a
> separate physical processor using /proc/irq/*/smp_affinity (especially
> when all the interrupts would hit the first CPU, another problem i've
> yet to address). That only works for real processors, though, not
> HT siblings.
>
> I'm writing a program to run on machines of unknown (by me)
> configuration, that will spread out the NIC interrupts appropriately.
> So userspace needs to know the difference, at least until interrupts
can
> be automatically distributed by the kernel in a satisfactory way.
>
> Jason
^ permalink raw reply
* How build dependencies work/are supposed to work in 2.5.5x
From: Petr Vandrovec @ 2003-01-09 22:33 UTC (permalink / raw)
To: linux-kernel
Hi,
I spent last few hours by patching 2.5.54-bk-something back and
forward to shrink Juriaans patch which reinstates 2.5.50 fbdev. Sometime
during this course something happened, and I ended up with incorrect
build: some code was thinking that "struct vc_data" contains
"vc_font" element, and some parts believed that there is no such element,
and structure is 24 bytes smaller (shifting vc_origin somewhere, causing
crash during bootup) :-( (there was such element, then there was not,
and then element arrived back during evening)
After I removed drivers/char/*.o and all .o from drivers/video subtree
and rerun "make", problem disappeared. During patching I never used -T/-Z
option to patch to set dates/times on files and I also did not use -j option
to make.
So I'd like to ask whether current kernel build system is supposed
to track changes in include files automagically, or whether I'm supposed
to run 'make dep' from time to time?
When I tried to recreate problem (by doing "touch
include/linux/console_struct.h"), all objects which use this file were
correctly rebuilt.
Thanks,
Petr Vandrovec
vandrove@vc.cvut.cz
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Jeff V. Merkey @ 2003-01-09 23:45 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel
In-Reply-To: <20030109222748.GA3993@gtf.org>
Jeff,
They only have to provide it if someone asks for it. I suggest sending them
a request asking for it to be disclosed and copy LKML on the request.
:-)
Jeff
(a great name to have)
On Thu, Jan 09, 2003 at 05:27:48PM -0500, Jeff Garzik wrote:
> Anybody know where the source rpm for UnitedLinux kernel is?
> [to be distinguished from kernel-source rpm]
>
> AFAICS they are not distributing source code to their published kernel
> binaries... which is a very obvious GPL violation.
>
> I'm also surprised the even-more-pro-GPL-than-me people have not jumped
> on UnitedLinux for not distributing source code.
>
> Jeff, looking for useful [rumored] drivers/net patches
>
>
>
> -
> 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-fbdev-devel] Re: rotation.
From: Linus Torvalds @ 2003-01-09 22:35 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1042153388.28469.17.camel@irongate.swansea.linux.org.uk>
In article <1042153388.28469.17.camel@irongate.swansea.linux.org.uk>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
>Note btw that the support ends rather abruptly on the console input side.
>There is no support for 3 or 4 byte utf8 input sequences and the delete
>key code in the kernel has no understanding of or support for UTF8
>deletion behaviour
UTF8 delete behaviour should be pretty trivial to add. It's liketly to
be more involved than simply adding a
/* multi-char UTF8 thing? Continue until we hit the first one */
if (tty->utf8 && (c & 0x80) && !(c & 0x40))
continue;
to the loop in n_tty.c: eraser(), but it might not be _much_ more than
that.
Linus
^ 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.