* RE: Access to Internal server via public address
From: Vernon A. Fort @ 2003-12-11 10:45 UTC (permalink / raw)
To: netfilter
In-Reply-To: <189F4CA4494FB344827F2A4FC0020C443906C7@stca437000.common.ecamericas>
My original reply does not look like it made the list. I shall try
again :)
First, I agree with all the responses. I have been working with
iptables for quite awhile but am no expert. I got caught up with the (I
just know I'm missing something) scenario - I thought I was just doing
something wrong. Apparently not!
I have toyed with the DNS server concept (I knew this was a easy way
around the problem) but never gave it much serious thought until Bill's
response which cleared up a few concepts for me.
I have gone the direction of an internal dns server to get around this
problem and it s working like a champ! I do appreciate ALL the input
and clarification.
Again - thanks for the imput!
Vernon Fort
On Wed, 2003-12-10 at 14:36, Hoeschen, Chris wrote:
> Can I ask why you want to access the internal server using the external
> IP address?
>
> To get around this for myself I setup a internal only DNS server inside
> my network to resolve names to internal IP addresses. This is separate
> from my externally facing DNS server that is resolving my external IP
> address to the DNS names. This way all I need to do is access my
> internal server via the DNS name instead of the IP address.
>
>
>
>
> Chris Hoeschen
> Distributed System Analysts
> PrimeVest Financial Services
> Phone: (320) 656-4035
> Fax: (320) 656-4088
> E-Mail: chris.hoeschen@primevest.net
>
>
> "Only two things are infinite, the universe and human stupidity, and I'm
> not sure about the former."
> -- Albert Einstein
>
> Hippopotomonstrosesquippedaliophobia is the fear of long words
>
>
>
> -----Original Message-----
> From: Antony Stone [mailto:Antony@Soft-Solutions.co.uk]
> Sent: Wednesday, December 10, 2003 2:26 PM
> To: netfilter
> Subject: Re: Access to Internal server via public address
>
>
> On Wednesday 10 December 2003 8:16 pm, William Stearns wrote:
>
> > Good afternoon, Vernon,
> >
> > On 10 Dec 2003, Vernon A. Fort wrote:
> > > Anyone,
> > >
> > > The Problem: I have an alias public address DNAT'ed to and
> > > internal address - normal and working
> > >
> > > What i need is to access this server using the PUBLIC address from
>
> > > an internal workstation.
>
> > If the client box and the internal server in question are on the
> same
> > cable, you essentially can't do this direcdtly (but read on).
> >
> > Picture this as a triangle; the internal machines on the bottom,
>
> > (client left, server right) and the firewall at the top. The packets
> > physically all travel over the same Ethernet segment shared by all
> > three machines, I'm just demonstrating who's talking to whom.
>
> Excellent answer, Bill.
>
> I think this explains a common situation (and a common FAQ) in more
> detail,
> and with more information, than I've seen before. Hopefully it is
> clear to
> a network non-expert as well (I don't use the term newbie here, because
> once
> you've got DNAT working at all, you've clearly gone beyond that
> stage...)
>
> Your reply is (IMHO) worthy of a FAQ entry in itself.
>
> Antony
^ permalink raw reply
* [parisc-linux] Sexy. leading men tricks to get any girl ra dfryux
From: Stephan Jennings @ 2003-12-11 6:38 UTC (permalink / raw)
To: parisc-linux
[-- Attachment #1: Type: text/html, Size: 1666 bytes --]
^ permalink raw reply
* Re: DNS with iptables
From: Maciej Soltysiak @ 2003-12-11 10:42 UTC (permalink / raw)
To: netfilter
In-Reply-To: <200312110959.11243.Antony@Soft-Solutions.co.uk>
> > Es geht um Dyndns und damit einem Problem...
> Ja, das ist ein Problem :(
You would have to remove the rule and insert it again, or just reload the
ruleset
everytime you detect the address has changed. It is possible, but
cumbersome.
Regards,
Maciej
^ permalink raw reply
* Re: 405 TLB miss reduction
From: Wolfgang Grandegger @ 2003-12-11 10:37 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <3FD75312.7070701@embeddededge.com>
On 12/10/2003 06:08 PM Dan Malek wrote:
> Wolfgang Grandegger wrote:
>
>> ....We
>> can regain a few percent by using the kernel option CONFIG_PIN_TLB
>> but we are thinking about further kernel modifications to reduce
>> TLB misses. What comes into my mind is:
>
> If you have a large application I doubt any kernel modification
> will gain much. It's the application causing the huge amounts
> of tlb misses, you probably need to evaluate changes that will
> reduce that.
>
> It's always easy to pick on the kernel and make some changes
> becaue it is a very static and well behaved application. It
> seems your biggest performance increase would come from the
> analysis of the application and some redesign to improve its
> use of system resources.
We have been surprised, that CONFIG_PIN_TLB was able to reduce the page
miss rate already by approx. 40%. We are also working on the
optimization/tuning of our application and likely there we can gain more
than by further squeezing the TBL management of the Linux kernel, I agree.
Thanks.
Wolfgang.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
From: Oliver Neukum @ 2003-12-11 10:19 UTC (permalink / raw)
To: Duncan Sands, Alan Stern
Cc: David Brownell, Vince, Randy.Dunlap, mfedyk, zwane, linux-kernel,
USB development list
In-Reply-To: <200312111045.11275.baldrick@free.fr>
Am Donnerstag, 11. Dezember 2003 10:45 schrieb Duncan Sands:
> > > > > __usb_set_configuration - lockless version
> > > > > usb_set_configuration - locked version
> > > >
> > > > Partially done.
> > > > That's what the _physical version of usb_reset_device() is about.
> > >
> > > Unfortunately, usb_physical_reset_device calls usb_set_configuration
> > > which takes dev->serialize.
> >
> > That is bad, but the solution is obvious.
> > All such operations need a _physical version.
> > At first sight this may look less elegant than some lock dropping schemes,
> > but it is a solution that produces obviously correct code paths with
> > respect to locking.
>
> Hi Oliver, I agree, except that there are several layers of locking: dev->serialize
> but also the bus rwsem. So does "physical" mean no subsys.rwsem or no
> dev->serialize or both?
"physical" means no locking at all. It's the caller's responsibility.
> int usb_reset_device(struct usb_device *udev)
> {
> struct device *gdev = &udev->dev;
> int r;
>
> down_read(&gdev->bus->subsys.rwsem);
> r = usb_physical_reset_device(udev);
> up_read(&gdev->bus->subsys.rwsem);
>
> return r;
> }
That's what the core cares about. No probe() while a reset is in
progress. Taking the semaphore ensures that.
Regards
Oliver
^ permalink raw reply
* Fwd: Re: System hanged for a kernel NULL pointer dereference in SLES8-UL1
From: Carlo @ 2003-12-11 10:20 UTC (permalink / raw)
To: linux-kernel; +Cc: ivan.sassi
I had the same problem with RedHat 7.3 and kernel 2.4.22 with raiserFS. The
system reply to ping bunt isn't accessible from SSH and http neither from
respond to keyboard keypressing.
The dmesg command return:
Dec 4 04:26:02 webeye kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000004
Dec 4 04:26:02 webeye kernel: printing eip:
Dec 4 04:26:02 webeye kernel: c0127d55
Dec 4 04:26:02 webeye kernel: *pde = 00000000
Dec 4 04:26:02 webeye kernel: Oops: 0002
Dec 4 04:26:02 webeye kernel: CPU: 0
Dec 4 04:26:02 webeye kernel: EIP: 0010:[<c0127d55>] Tainted: P
Dec 4 04:26:02 webeye kernel: EFLAGS: 00010202
Dec 4 04:26:02 webeye kernel: eax: 00000000 ebx: ca4df864 ecx: c0190f30
edx: 00000000
Dec 4 04:26:02 webeye kernel: esi: ca4df834 edi: 00000000 ebp: ca4df844
esp: cff2bf78
Dec 4 04:26:02 webeye kernel: ds: 0018 es: 0018 ss: 0018
Dec 4 04:26:02 webeye kernel: Process kupdated (pid: 6, stackpage=cff2b000)
Dec 4 04:26:02 webeye kernel: Stack: ca4df780 ca4df780 ca4df780 cfe3085c
c0147667 ca4df834 cfe30800 cff2bf9c
Dec 4 04:26:02 webeye kernel: cff2bf9c 00000000 00000000 0066286a
cff2a000 c01159a0 c03b4d60 cff2a000
Dec 4 04:26:02 webeye kernel: cff2a560 cff2a560 cff2a000 c01392d5
c013957c c0385e90 c12ddf98 c0105000
Dec 4 04:26:02 webeye kernel: Call Trace: [<c0147667>] [<c01159a0>]
[<c01392d5>]
[<c013957c>] [<c0105000>]
Dec 4 04:26:02 webeye kernel: [<c0105000>] [<c0107116>] [<c01394a0>]
Dec 4 04:26:02 webeye kernel:
Dec 4 04:26:02 webeye kernel: Code: 89 50 04 89 02 c7 03 00 00 00 00 c7 43
04 00 00
00 00 8b 06
Alle 15:11, venerdì 28 novembre 2003, Ivan Sassi ha scritto:
> System hanged for a kernel NULL pointer dereference in SLES8-UL1
>
> The system (an IBM xSeries 440 4way xeon 2.4 MHz RAM 4 Gb) hanged whit
> the previus error. The machine continued to reply at ping requestes but
> no shell at all was accessible (the SSL connection also don't worked)...
> I restarted the machine (hard power reset) and the system seems to have
> no problem at all... but the server works as TSM server and runs the
> backup of VERY iportant data, so the maximun stability is absolutly
> necesary...
>
> Result of ps -ef:
>
> UID PID PPID C STIME TTY TIME CMD
> root 1 0 0 Nov27 ? 00:00:24 init
> root 2 1 0 Nov27 ? 00:00:00 [migration_CPU0]
> root 3 1 0 Nov27 ? 00:00:00 [migration_CPU1]
> root 4 1 0 Nov27 ? 00:00:00 [migration_CPU2]
> root 5 1 0 Nov27 ? 00:00:00 [migration_CPU3]
> root 6 1 0 Nov27 ? 00:00:08 [keventd]
> root 7 1 0 Nov27 ? 00:01:21 [ksoftirqd_CPU0]
> root 8 1 0 Nov27 ? 00:01:20 [ksoftirqd_CPU1]
> root 9 1 0 Nov27 ? 00:00:46 [ksoftirqd_CPU2]
> root 10 1 0 Nov27 ? 00:00:43 [ksoftirqd_CPU3]
> root 11 1 0 Nov27 ? 00:14:52 [kswapd]
> root 12 1 0 Nov27 ? 00:00:01 [bdflush]
> root 13 1 0 Nov27 ? 00:00:09 [kupdated]
> root 14 1 0 Nov27 ? 00:00:00 [kinoded]
> root 16 1 0 Nov27 ? 00:00:00 [mdrecoveryd]
> root 19 1 0 Nov27 ? 00:00:00 [qla2300_dpc0]
> root 20 1 0 Nov27 ? 00:00:00 [scsi_eh_0]
> root 22 1 0 Nov27 ? 00:00:00 [ahc_dv_0]
> root 23 1 0 Nov27 ? 00:00:00 [ahc_dv_1]
> root 24 1 0 Nov27 ? 00:00:00 [ahc_dv_2]
> root 25 1 0 Nov27 ? 00:00:00 [ahc_dv_3]
> root 26 1 0 Nov27 ? 00:00:00 [scsi_eh_1]
> root 27 1 0 Nov27 ? 00:00:00 [scsi_eh_2]
> root 28 1 0 Nov27 ? 00:00:00 [scsi_eh_3]
> root 29 1 0 Nov27 ? 00:00:00 [scsi_eh_4]
> root 33 1 0 Nov27 ? 00:00:11 [kjournald]
> root 92 1 0 Nov27 ? 00:00:00 [lvm-mpd]
> root 133 1 0 Nov27 ? 00:00:00 [kjournald]
> root 134 1 0 Nov27 ? 00:03:07 [kjournald]
> root 135 1 0 Nov27 ? 00:01:16 [kjournald]
> root 136 1 0 Nov27 ? 00:02:14 [kjournald]
> root 461 1 0 Nov27 ? 00:00:00 /sbin/syslogd
> root 464 1 0 Nov27 ? 00:00:00 /sbin/klogd -c 1 -2
> root 500 1 0 Nov27 ? 00:00:00 [khubd]
> bin 627 1 0 Nov27 ? 00:00:00 /sbin/portmap
> root 670 1 0 Nov27 ? 00:00:00 /usr/sbin/sshd
> root 931 1 0 Nov27 ? 00:00:03 /usr/lib/postfix/master
> at 954 1 0 Nov27 ? 00:00:00 /usr/sbin/atd
> postfix 964 931 0 Nov27 ? 00:00:01 qmgr -l -t fifo -u
> root 971 1 0 Nov27 ? 00:00:02 /usr/sbin/cron
> root 1064 1 0 Nov27 ? 00:00:01 /usr/sbin/nscd
> root 1065 1064 0 Nov27 ? 00:00:00 /usr/sbin/nscd
> root 1066 1065 0 Nov27 ? 00:00:01 /usr/sbin/nscd
> root 1067 1065 0 Nov27 ? 00:00:00 /usr/sbin/nscd
> root 1068 1065 0 Nov27 ? 00:00:00 /usr/sbin/nscd
> root 1069 1065 0 Nov27 ? 00:00:00 /usr/sbin/nscd
> root 1070 1065 0 Nov27 ? 00:00:00 /usr/sbin/nscd
> root 1081 1 0 Nov27 ? 00:00:00 /usr/sbin/inetd
> root 1098 1 0 Nov27 ? 00:00:00
> /opt/IBM_FAStT/jre/bin/i386/native_threads/java -classpath
> /opt/IBM_FAStT/clie
> root 1107 1 0 Nov27 tty3 00:00:00 /sbin/mingetty tty3
> root 1109 1 0 Nov27 tty4 00:00:00 /sbin/mingetty tty4
> root 1111 1 0 Nov27 tty5 00:00:00 /sbin/mingetty tty5
> root 1112 1 0 Nov27 tty6 00:00:00 /sbin/mingetty tty6
> root 1126 1 0 Nov27 ? 00:00:42 /usr/bin/IBMtaped
> root 1141 1098 0 Nov27 ? 00:00:00
> /opt/IBM_FAStT/jre/bin/i386/native_threads/java -classpath
> /opt/IBM_FAStT/clie
> root 1142 1141 0 Nov27 ? 00:00:00
> /opt/IBM_FAStT/jre/bin/i386/native_threads/java -classpath
> /opt/IBM_FAStT/clie
> root 1143 1141 0 Nov27 ? 00:00:00
> /opt/IBM_FAStT/jre/bin/i386/native_threads/java -classpath
> /opt/IBM_FAStT/clie
> root 1144 1141 0 Nov27 ? 00:00:00
> /opt/IBM_FAStT/jre/bin/i386/native_threads/java -classpath
> /opt/IBM_FAStT/clie
> root 1145 1141 0 Nov27 ? 00:00:20
> /opt/IBM_FAStT/jre/bin/i386/native_threads/java -classpath
> /opt/IBM_FAStT/clie
> root 1146 1141 0 Nov27 ? 00:00:00
> /opt/IBM_FAStT/jre/bin/i386/native_threads/java -classpath
> /opt/IBM_FAStT/clie
> root 1147 1141 0 Nov27 ? 00:00:00
> /opt/IBM_FAStT/jre/bin/i386/native_threads/java -classpath
> /opt/IBM_FAStT/clie
> root 1148 1141 0 Nov27 ? 00:00:00
> /opt/IBM_FAStT/jre/bin/i386/native_threads/java -classpath
> /opt/IBM_FAStT/clie
> root 1149 1141 0 Nov27 ? 00:00:00
> /opt/IBM_FAStT/jre/bin/i386/native_threads/java -classpath
> /opt/IBM_FAStT/clie
> root 1150 1141 0 Nov27 ? 00:00:00
> /opt/IBM_FAStT/jre/bin/i386/native_threads/java -classpath
> /opt/IBM_FAStT/clie
> root 1151 1141 0 Nov27 ? 00:00:00
> /opt/IBM_FAStT/jre/bin/i386/native_threads/java -classpath
> /opt/IBM_FAStT/clie
> root 1152 1141 0 Nov27 ? 00:00:00
> /opt/IBM_FAStT/jre/bin/i386/native_threads/java -classpath
> /opt/IBM_FAStT/clie
> root 1365 1 0 Nov27 ? 00:00:06 ./dsmserv
> root 1366 1365 0 Nov27 ? 00:00:01 ./dsmserv
> root 1368 1366 0 Nov27 ? 00:01:37 ./dsmserv
> root 1369 1366 0 Nov27 ? 00:01:15 ./dsmserv
> root 1370 1366 0 Nov27 ? 00:01:40 ./dsmserv
> root 1371 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1372 1366 0 Nov27 ? 00:01:57 ./dsmserv
> root 1373 1366 0 Nov27 ? 00:00:06 ./dsmserv
> root 1374 1366 0 Nov27 ? 00:00:06 ./dsmserv
> root 1375 1366 0 Nov27 ? 00:00:31 ./dsmserv
> root 1376 1366 0 Nov27 ? 00:00:01 ./dsmserv
> root 1377 1366 0 Nov27 ? 00:00:02 ./dsmserv
> root 1387 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1388 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1390 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1391 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1392 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1394 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1397 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1398 1366 0 Nov27 ? 00:02:22 ./dsmserv
> root 1401 1366 0 Nov27 ? 00:09:33 ./dsmserv
> root 1404 1366 0 Nov27 ? 00:09:13 ./dsmserv
> root 1406 1366 0 Nov27 ? 00:02:35 ./dsmserv
> root 1409 1366 0 Nov27 ? 00:02:21 ./dsmserv
> root 1410 1366 0 Nov27 ? 00:02:22 ./dsmserv
> root 1413 1366 0 Nov27 ? 00:02:15 ./dsmserv
> root 1415 1366 0 Nov27 ? 00:04:25 ./dsmserv
> root 1417 1366 0 Nov27 ? 00:02:34 ./dsmserv
> root 1420 1366 0 Nov27 ? 00:14:07 ./dsmserv
> root 1423 1366 0 Nov27 ? 00:04:47 ./dsmserv
> root 1425 1366 0 Nov27 ? 00:05:07 ./dsmserv
> root 1427 1366 0 Nov27 ? 00:03:20 ./dsmserv
> root 1429 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1430 1366 0 Nov27 ? 00:05:06 ./dsmserv
> root 1431 1366 0 Nov27 ? 00:06:34 ./dsmserv
> root 1432 1366 0 Nov27 ? 00:05:04 ./dsmserv
> root 1433 1366 0 Nov27 ? 00:00:46 ./dsmserv
> root 1434 1366 0 Nov27 ? 00:03:01 ./dsmserv
> root 1435 1366 0 Nov27 ? 00:02:06 ./dsmserv
> root 1436 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1437 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1438 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1439 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1442 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1443 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1444 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1445 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1446 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1447 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1449 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1451 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1452 1366 0 Nov27 ? 00:00:00 ./dsmserv
> root 1488 1 0 Nov27 tty2 00:00:00 /sbin/mingetty tty2
> root 1512 1 0 Nov27 tty1 00:00:00 /sbin/mingetty --noclear
> tty1
> root 3522 1366 0 Nov27 ? 00:00:00 ./dsmserv
> postfix 8159 931 0 13:45 ? 00:00:00 pickup -l -t fifo -u
> root 8248 670 0 14:28 ? 00:00:00 /usr/sbin/sshd
> root 8250 8248 0 14:28 pts/0 00:00:00 -bash
> root 8400 8250 0 14:54 pts/0 00:00:00 ps -ef
>
> Result of cat /proc/version:
>
> Linux version 2.4.19-64GB-SMP (root@SMP_X86.suse.de) (gcc version 3.2.2)
> #1 SMP Mon Aug 4 23:48:22 UTC 2003
>
> Output of Oops.. message:
>
> Nov 26 22:31:55 SSILXTSM kernel: Unable to handle kernel NULL pointer
> dereference at virtual address 00000004
> Nov 26 22:31:55 SSILXTSM kernel: printing eip:
> Nov 26 22:31:55 SSILXTSM kernel: c015633b
> Nov 26 22:31:55 SSILXTSM kernel: *pde = 0b61a001
> Nov 26 22:31:55 SSILXTSM kernel: Oops: 0002 2.4.19-64GB-SMP #1 SMP Mon
> Aug 4 23:48:22 UTC 2003
> Nov 26 22:31:55 SSILXTSM kernel: CPU: 1
> Nov 26 22:31:55 SSILXTSM kernel: EIP: 0010:[sys_close+27/128] Not
> tainted
> Nov 26 22:31:55 SSILXTSM kernel: EIP: 0010:[<c015633b>] Not tainted
> Nov 26 22:31:55 SSILXTSM kernel: EFLAGS: 00010286
> Nov 26 22:31:55 SSILXTSM kernel: eax: 00000004 ebx: d75fe000 ecx:
> 00000023 edx: 00000000
> Nov 26 22:31:55 SSILXTSM kernel: esi: 0000005c edi: 00000000 ebp:
> b79fb454 esp: d75fffb4
> Nov 26 22:31:55 SSILXTSM kernel: ds: 0018 es: 0018 ss: 0018
> Nov 26 22:31:55 SSILXTSM kernel: Process dsmserv (pid: 6653,
> stackpage=d75ff000)
> Nov 26 22:31:55 SSILXTSM kernel: Stack: b79ffc00 00000000 d75fe000
> c01095ef 00000023 00000000 4006fac0 0000005c
> Nov 26 22:31:55 SSILXTSM kernel: 00000000 b79fb454 00000006
> 0000002b 0000002b 00000006 40132a4d 00000023
> Nov 26 22:31:55 SSILXTSM kernel: 00000246 b79fb438 0000002b
> Nov 26 22:31:55 SSILXTSM kernel: Call Trace: [system_call+51/56]
> Nov 26 22:31:55 SSILXTSM kernel: Call Trace: [<c01095ef>]
> Nov 26 22:31:55 SSILXTSM kernel: Code: f0 81 28 00 00 00 01 0f 85 04 07
> 00 00 3b 4a 08 73 43 8b 42
>
> The are no apparent trigger to the error status...
>
> The distro is a SLES8 powered by UnitedLinux 1.0... the only upgrade was
> to the kernel k_smp-2.4.19-340...
>
> Result of sh /usr/src/linux/scripts/ver_linux:
>
> Linux SSILXTSM 2.4.19-64GB-SMP #1 SMP Mon Aug 4 23:48:22 UTC 2003 i686
> unknown
>
> Gnu C gcc (GCC) 3.2 Copyright (C) 2002 Free Software
> Foundation, Inc. This is free software; see the source for copying
> conditions. There is NO warranty; not even for MERCHANTABILITY or
> FITNESS FOR A PARTICULAR PURPOSE.
> Gnu make 3.79.1
> util-linux 2.11u
> mount 2.11u
> modutils 2.4.19
> e2fsprogs 1.28
> PPP 2.4.1
> isdn4k-utils 3.2p1
> Linux C Library x 1 root root 1312470 Oct 22 2002
> /lib/libc.so.6
> Dynamic linker (ldd) 2.2.5
> Linux C++ Library 5.0.0
> Procps 2.0.7
> Net-tools 1.60
> Kbd 1.06
> Sh-utils 2.0
> Modules Loaded ide-cd isa-pnp ipv6 st sr_mod cdrom sg joydev
> evdev input usb-uhci usbcore bcm5700 lvm-mod ext3 jbd IBMtape aic7xxx
> qla2300
>
> Result of cat /proc/cpuinfo:
>
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 15
> model : 2
> model name : Intel(R) Xeon(TM) CPU 2.40GHz
> stepping : 7
> cpu MHz : 2395.205
> cache size : 512 KB
> physical id : 0
> siblings : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 2
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
> bogomips : 198.65
>
> processor : 1
> vendor_id : GenuineIntel
> cpu family : 15
> model : 2
> model name : Intel(R) Xeon(TM) CPU 2.40GHz
> stepping : 7
> cpu MHz : 2395.205
> cache size : 512 KB
> physical id : 0
> siblings : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 2
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
> bogomips : 199.47
>
> processor : 2
> vendor_id : GenuineIntel
> cpu family : 15
> model : 2
> model name : Intel(R) Xeon(TM) CPU 2.40GHz
> stepping : 7
> cpu MHz : 2395.205
> cache size : 512 KB
> physical id : 0
> siblings : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 2
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
> bogomips : 199.47
>
> processor : 3
> vendor_id : GenuineIntel
> cpu family : 15
> model : 2
> model name : Intel(R) Xeon(TM) CPU 2.40GHz
> stepping : 7
> cpu MHz : 2395.205
> cache size : 512 KB
> physical id : 0
> siblings : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 2
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
> bogomips : 199.47
>
> Result of cat /proc/modules:
>
> ide-cd 30564 0 (autoclean)
> isa-pnp 32512 0 (unused)
> ipv6 268124 -1 (autoclean)
> st 29324 0 (autoclean)
> sr_mod 14520 0 (autoclean) (unused)
> cdrom 29056 0 (autoclean) [ide-cd sr_mod]
> sg 30368 0 (autoclean)
> joydev 6112 0 (unused)
> evdev 4800 0 (unused)
> input 3488 0 [joydev evdev]
> usb-uhci 24460 0 (unused)
> usbcore 64960 1 [usb-uhci]
> bcm5700 86280 2
> lvm-mod 68256 0 (autoclean)
> ext3 89160 5
> jbd 54020 5 [ext3]
> IBMtape 167141 1
> aic7xxx 179108 0
> qla2300 236096 6
>
> Result of cat /proc/ioports:
>
> 0000-001f : dma1
> 0020-003f : pic1
> 0040-005f : timer
> 0060-006f : keyboard
> 0070-007f : rtc
> 0080-008f : dma page reg
> 00a0-00bf : pic2
> 00c0-00df : dma2
> 00f0-00ff : fpu
> 01f0-01f7 : ide0
> 03c0-03df : vesafb
> 03f6-03f6 : ide0
> 0440-044f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
> 0700-070f : VIA Technologies, Inc. VT82C586B PIPC Bus Master IDE
> 0700-0707 : ide0
> 0708-070f : ide1
> 0cf8-0cff : PCI conf1
> 1800-187f : PCI device 1014:010f (IBM)
> 1880-189f : VIA Technologies, Inc. USB
> 1880-189f : usb-uhci
> 18a0-18bf : VIA Technologies, Inc. USB (#2)
> 18a0-18bf : usb-uhci
> 3000-30ff : QLogic Corp. QLA2312 Fibre Channel Adapter
> 3000-30fe : qla2300
> 3800-38ff : Adaptec AHA-3960D / AIC-7899A U160/m
> 3800-38ff : aic7xxx
> 3900-39ff : Adaptec AHA-3960D / AIC-7899A U160/m (#2)
> 3900-39ff : aic7xxx
> 3a00-3aff : Adaptec AHA-3960D / AIC-7899A U160/m (#3)
> 3a00-3aff : aic7xxx
> 3b00-3bff : Adaptec AHA-3960D / AIC-7899A U160/m (#4)
> 3b00-3bff : aic7xxx
>
> Result of cat /proc/iomem:
>
> 00000000-0009d7ff : System RAM
> 0009d800-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000c7fff : Video ROM
> 000c8000-000c97ff : Extension ROM
> 000c9800-000cafff : Extension ROM
> 000cb000-000cd9ff : Extension ROM
> 000f0000-000fffff : System ROM
> 00100000-dffb6fbf : System RAM
> 00100000-002e3f65 : Kernel code
> 002e3f66-0037d39f : Kernel data
> dffb6fc0-dffbf7ff : ACPI Tables
> dffbf800-dfffffff : reserved
> e0000000-e7ffffff : S3 Inc. Savage 4
> e0000000-e07fffff : vesafb
> f0410000-f041ffff : PCI device 14e4:1648 (Broadcom Corporation)
> f0410000-f041ffff : bcm5700
> f0420000-f042ffff : PCI device 14e4:1648 (Broadcom Corporation)
> f0420000-f042ffff : bcm5700
> f0430000-f043ffff : PCI device 14e4:1648 (Broadcom Corporation)
> f0430000-f043ffff : bcm5700
> f0440000-f044ffff : PCI device 14e4:1648 (Broadcom Corporation)
> f0440000-f044ffff : bcm5700
> f0800000-f09fffff : PCI device 1014:010f (IBM)
> f0a00000-f0a7ffff : S3 Inc. Savage 4
> f0e00000-f0e0ffff : Broadcom Corporation NetXtreme BCM5700 Gigabit Ethernet
> f0e00000-f0e0ffff : bcm5700
> fb620000-fb620fff : QLogic Corp. QLA2312 Fibre Channel Adapter
> fb720000-fb720fff : Adaptec AHA-3960D / AIC-7899A U160/m
> fb720000-fb720fff : aic7xxx
> fb721000-fb721fff : Adaptec AHA-3960D / AIC-7899A U160/m (#2)
> fb721000-fb721fff : aic7xxx
> fb722000-fb722fff : Adaptec AHA-3960D / AIC-7899A U160/m (#3)
> fb722000-fb722fff : aic7xxx
> fb723000-fb723fff : Adaptec AHA-3960D / AIC-7899A U160/m (#4)
> fb723000-fb723fff : aic7xxx
> fec00000-ffffffff : reserved
>
> Result of lspci -vvv:
>
> 00:00.0 Host bridge: IBM: Unknown device 0302 (rev 03)
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+ Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort-
> <TAbort- <MAbort+ >SERR- <PERR-
> Latency: 240
> Capabilities: [60] PCI-X non-bridge device.
> Command: DPERE- ERO- RBC=0 OST=1
> Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-,
> DC=simple, DMMRBC=0, DMOST=0, DMCRS=0, RSCEM-
> 00:03.0 VGA compatible controller: S3 Inc. Savage 4 (rev 06) (prog-if 00
> [VGA])
> Subsystem: IBM: Unknown device 01c5
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+ Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
>
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Latency: 248 (1000ns min, 63750ns max), cache line size 10
> Interrupt: pin A routed to IRQ 39
> Region 0: Memory at f0a00000 (32-bit, non-prefetchable)
> [size=512K] Region 1: Memory at e0000000 (32-bit, prefetchable) [size=128M]
> Expansion ROM at <unassigned> [disabled] [size=64K]
> Capabilities: [dc] Power Management version 2
> Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:04.0 Bridge: IBM: Unknown device 010f
> Subsystem: IBM: Unknown device 0113
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+ Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
>
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Latency: 247 (1000ns min, 2000ns max), cache line size 10
> Interrupt: pin A routed to IRQ 16
> BIST result: 00
> Region 0: Memory at f0800000 (64-bit, non-prefetchable) [size=2M]
> Region 2: I/O ports at 1800 [size=128]
> Expansion ROM at <unassigned> [disabled] [size=2M]
> Capabilities: [48] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:05.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South]
> (rev 40)
> Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
>
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Latency: 0
> Capabilities: [c0] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:05.1 IDE interface: VIA Technologies, Inc. VT82C586B PIPC Bus Master
> IDE (rev 06) (prog-if 8a [Master SecP PriP])
> Subsystem: VIA Technologies, Inc. (Wrong ID): Unknown device 1234
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium
>
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Latency: 240
> Region 4: I/O ports at 0700 [size=16]
> Capabilities: [c0] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:05.2 USB Controller: VIA Technologies, Inc. USB (rev 16) (prog-if 00
> [UHCI])
> Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
>
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Latency: 240, cache line size 10
> Interrupt: pin D routed to IRQ 18
> Region 4: I/O ports at 1880 [size=32]
> Capabilities: [80] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:05.3 USB Controller: VIA Technologies, Inc. USB (rev 16) (prog-if 00
> [UHCI])
> Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
>
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Latency: 240, cache line size 10
> Interrupt: pin D routed to IRQ 18
> Region 4: I/O ports at 18a0 [size=32]
> Capabilities: [80] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:05.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
> Subsystem: VIA Technologies, Inc. (Wrong ID): Unknown device 1234
> Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium
>
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Capabilities: [68] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 01:00.0 Host bridge: IBM: Unknown device 0302 (rev 03)
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+ Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort-
> <TAbort- <MAbort+ >SERR- <PERR-
> Latency: 240
> Capabilities: [60] PCI-X non-bridge device.
> Command: DPERE- ERO- RBC=0 OST=1
> Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-,
> DC=simple, DMMRBC=0, DMOST=0, DMCRS=0, RSCEM-
> 01:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5700
> Gigabit Ethernet (rev 12)
> Subsystem: IBM Broadcom Vigil B5700 1000BaseTX
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+ Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Latency: 240 (16000ns min), cache line size 10
> Interrupt: pin A routed to IRQ 42
> Region 0: Memory at f0e00000 (64-bit, non-prefetchable) [size=64K]
> Capabilities: [40] PCI-X non-bridge device.
> Command: DPERE- ERO+ RBC=3 OST=6
> Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-,
> DC=simple, DMMRBC=0, DMOST=0, DMCRS=0, RSCEM- Capabilities: [48]
> Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [50] Vital Product Data
> Capabilities: [58] Message Signalled Interrupts: 64bit+
> Queue=0/3 Enable-
> Address: 94aad0631e01a210 Data: 3a3b
>
> 02:00.0 Host bridge: IBM: Unknown device 0302 (rev 03)
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+ Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort-
> <TAbort- <MAbort+ >SERR- <PERR-
> Latency: 240
> Capabilities: [60] PCI-X non-bridge device.
> Command: DPERE- ERO- RBC=0 OST=1
> Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-,
> DC=simple, DMMRBC=0, DMOST=0, DMCRS=0, RSCEM-
> 02:02.0 Ethernet controller: Broadcom Corporation: Unknown device 1648
> (rev 03)
> Subsystem: Broadcom Corporation: Unknown device 1648
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+ Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Latency: 240 (16000ns min), cache line size 10
> Interrupt: pin A routed to IRQ 55
> Region 0: Memory at f0410000 (64-bit, non-prefetchable) [size=64K]
> Region 2: Memory at f0420000 (64-bit, non-prefetchable) [size=64K]
> Expansion ROM at <unassigned> [disabled] [size=64K]
> Capabilities: [40] PCI-X non-bridge device.
> Command: DPERE- ERO- RBC=2 OST=0
> Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-,
> DC=simple, DMMRBC=0, DMOST=0, DMCRS=0, RSCEM- Capabilities: [48]
> Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable+ DSel=0 DScale=1 PME-
> Capabilities: [50] Vital Product Data
> Capabilities: [58] Message Signalled Interrupts: 64bit+
> Queue=0/3 Enable-
> Address: 2804801110811200 Data: 2260
>
> 02:02.1 Ethernet controller: Broadcom Corporation: Unknown device 1648
> (rev 03)
> Subsystem: Broadcom Corporation: Unknown device 1648
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+ Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Latency: 240 (16000ns min), cache line size 10
> Interrupt: pin B routed to IRQ 56
> Region 0: Memory at f0430000 (64-bit, non-prefetchable) [size=64K]
> Region 2: Memory at f0440000 (64-bit, non-prefetchable) [size=64K]
> Capabilities: [40] PCI-X non-bridge device.
> Command: DPERE- ERO- RBC=2 OST=0
> Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-,
> DC=simple, DMMRBC=0, DMOST=0, DMCRS=0, RSCEM- Capabilities: [48]
> Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable+ DSel=0 DScale=1 PME-
> Capabilities: [50] Vital Product Data
> Capabilities: [58] Message Signalled Interrupts: 64bit+
> Queue=0/3 Enable-
> Address: 0004205020500000 Data: 0c02
>
> 05:00.0 Host bridge: IBM: Unknown device 0302 (rev 03)
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+ Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort-
> <TAbort- <MAbort+ >SERR- <PERR-
> Latency: 240
> Capabilities: [60] PCI-X non-bridge device.
> Command: DPERE- ERO- RBC=0 OST=1
> Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-,
> DC=simple, DMMRBC=0, DMOST=0, DMCRS=0, RSCEM-
> 05:04.0 Fibre Channel: QLogic Corp. QLA2312 Fibre Channel Adapter (rev 02)
> Subsystem: QLogic Corp.: Unknown device 0100
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> ParErr+ Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium
>
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Latency: 240 (16000ns min), cache line size 10
> Interrupt: pin A routed to IRQ 71
> Region 0: I/O ports at 3000 [size=256]
> Region 1: Memory at fb620000 (64-bit, non-prefetchable) [size=4K]
> Expansion ROM at <unassigned> [disabled] [size=128K]
> Capabilities: [44] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [4c] PCI-X non-bridge device.
> Command: DPERE- ERO+ RBC=3 OST=6
> Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-,
> DC=simple, DMMRBC=0, DMOST=0, DMCRS=0, RSCEM- Capabilities: [54]
> Message Signalled Interrupts: 64bit+ Queue=0/3 Enable-
> Address: 0000000000000000 Data: 0000
> Capabilities: [64] #06 [0080]
>
> 07:00.0 Host bridge: IBM: Unknown device 0302 (rev 03)
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+ Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort-
> <TAbort- <MAbort+ >SERR- <PERR-
> Latency: 240
> Capabilities: [60] PCI-X non-bridge device.
> Command: DPERE- ERO- RBC=0 OST=1
> Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-,
> DC=simple, DMMRBC=0, DMOST=0, DMCRS=0, RSCEM-
> 09:00.0 Host bridge: IBM: Unknown device 0302 (rev 03)
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+ Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort-
> <TAbort- <MAbort+ >SERR- <PERR-
> Latency: 240
> Capabilities: [60] PCI-X non-bridge device.
> Command: DPERE- ERO- RBC=0 OST=1
> Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-,
> DC=simple, DMMRBC=0, DMOST=0, DMCRS=0, RSCEM-
> 09:01.0 SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m
> (rev 01)
> Subsystem: Adaptec AHA-3960D U160/m
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Latency: 240 (10000ns min, 6250ns max), cache line size 10
> Interrupt: pin A routed to IRQ 59
> BIST result: 00
> Region 0: I/O ports at 3800 [disabled] [size=256]
> Region 1: Memory at fb720000 (64-bit, non-prefetchable) [size=4K]
> Expansion ROM at <unassigned> [disabled] [size=128K]
> Capabilities: [dc] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 09:01.1 SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m
> (rev 01)
> Subsystem: Adaptec AHA-3960D U160/m
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Latency: 240 (10000ns min, 6250ns max), cache line size 10
> Interrupt: pin B routed to IRQ 60
> BIST result: 00
> Region 0: I/O ports at 3900 [disabled] [size=256]
> Region 1: Memory at fb721000 (64-bit, non-prefetchable) [size=4K]
> Expansion ROM at <unassigned> [disabled] [size=128K]
> Capabilities: [dc] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 09:02.0 SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m
> (rev 01)
> Subsystem: Adaptec AHA-3960D U160/m
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Latency: 240 (10000ns min, 6250ns max), cache line size 10
> Interrupt: pin A routed to IRQ 63
> BIST result: 00
> Region 0: I/O ports at 3a00 [disabled] [size=256]
> Region 1: Memory at fb722000 (64-bit, non-prefetchable) [size=4K]
> Expansion ROM at <unassigned> [disabled] [size=128K]
> Capabilities: [dc] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 09:02.1 SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m
> (rev 01)
> Subsystem: Adaptec AHA-3960D U160/m
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Latency: 240 (10000ns min, 6250ns max), cache line size 10
> Interrupt: pin B routed to IRQ 64
> BIST result: 00
> Region 0: I/O ports at 3b00 [disabled] [size=256]
> Region 1: Memory at fb723000 (64-bit, non-prefetchable) [size=4K]
> Expansion ROM at <unassigned> [disabled] [size=128K]
> Capabilities: [dc] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> Result of cat /proc/scsi/scsi:
>
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
> Vendor: IBM Model: 1742 Rev: 0520
> Type: Direct-Access ANSI SCSI revision: 03
> Host: scsi0 Channel: 00 Id: 00 Lun: 01
> Vendor: IBM Model: 1742 Rev: 0520
> Type: Direct-Access ANSI SCSI revision: 03
> Host: scsi0 Channel: 00 Id: 00 Lun: 02
> Vendor: IBM Model: 1742 Rev: 0520
> Type: Direct-Access ANSI SCSI revision: 03
> Host: scsi0 Channel: 00 Id: 00 Lun: 03
> Vendor: IBM Model: 1742 Rev: 0520
> Type: Direct-Access ANSI SCSI revision: 03
> Host: scsi1 Channel: 00 Id: 05 Lun: 00
> Vendor: IBM Model: ULT3580-TD2 Rev: 3A30
> Type: Sequential-Access ANSI SCSI revision: 03
> Host: scsi2 Channel: 00 Id: 03 Lun: 00
> Vendor: IBM Model: ULT3580-TD2 Rev: 3A30
> Type: Sequential-Access ANSI SCSI revision: 03
> Host: scsi2 Channel: 00 Id: 04 Lun: 00
> Vendor: IBM Model: ULT3580-TD2 Rev: 3A30
> Type: Sequential-Access ANSI SCSI revision: 03
> Host: scsi3 Channel: 00 Id: 00 Lun: 00
> Vendor: IBM Model: ULT3580-TD2 Rev: 3A30
> Type: Sequential-Access ANSI SCSI revision: 03
> Host: scsi3 Channel: 00 Id: 00 Lun: 01
> Vendor: IBM Model: 03584L32 Rev: 3480
> Type: Medium Changer ANSI SCSI revision: 03
> Host: scsi3 Channel: 00 Id: 01 Lun: 00
> Vendor: IBM Model: ULT3580-TD2 Rev: 3A30
> Type: Sequential-Access ANSI SCSI revision: 03
> Host: scsi4 Channel: 00 Id: 02 Lun: 00
> Vendor: IBM Model: ULT3580-TD2 Rev: 3A30
> Type: Sequential-Access ANSI SCSI revision: 03
-------------------------------------------------------
-------------------------------------------------------
^ permalink raw reply
* Re: 2.6.0-test9 - poor swap performance on low end machines
From: Roger Luethi @ 2003-12-11 10:16 UTC (permalink / raw)
To: Rik van Riel
Cc: William Lee Irwin III, Con Kolivas, Chris Vine, linux-kernel,
Martin J. Bligh
In-Reply-To: <Pine.LNX.4.44.0312102027001.25222-100000@chimarrao.boston.redhat.com>
On Wed, 10 Dec 2003 20:31:40 -0500, Rik van Riel wrote:
> Hmmm, those definitions have changed a little from the
> OS books I read ;))
>
> > - It is light thrashing when load control has no advantage.
>
> This used to be called "no thrashing" ;)
Fair enough, but that was before Linux 2.6 <g>.
kbuild benchmark, execution time in seconds (median over ten runs):
74 2.6.0-test11, 256 MB RAM
115 2.4.21, 64 MB RAM
539 2.6.0-test11, 64 MB RAM
We can call it lousy paging, that'll be fine with me.
> Also, it would make the job of a load control mechanism
> really easy to define:
>
> "Prevent the system from thrashing"
"... once all other means are exhausted". Then I'll buy it.
Roger
^ permalink raw reply
* Re: 2.6.0-test9 - poor swap performance on low end machines
From: Roger Luethi @ 2003-12-11 10:16 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: William Lee Irwin III, Con Kolivas, Chris Vine, Rik van Riel,
linux-kernel, Martin J. Bligh
In-Reply-To: <20031210224445.GE11193@dualathlon.random>
On Wed, 10 Dec 2003 23:44:46 +0100, Andrea Arcangeli wrote:
> more processes can be optimized even better by adding unfariness.
> Either ways a significant slowdown of qsbench probably means worse core
> VM, at least if compared with 2.4 that isn't adding huge unfariness just
> to optimize qsbench.
Can you be a bit more specific about the type of unfairness? The only
instance I clearly noticed is that one process can grow its RSS at the
expense of others if they already have a high PFF. That happens more
often in 2.4 and helps a lot with some benchmarks.
I did notice, though, that after an initial slowdown, qsbench improved
during 2.5, while the compile benchmarks got even worse.
> > Also, the 2.6 core VM doesn't seem all that bad since it was introduced in
> > 2.5.27 but most of the problems I measured were introduced after 2.5.40.
> > Check out the graph I posted.
>
> you're confusing rmap with core vm. rmap in no way can be defined as the
> core vm, rmap is just a method used by the core vm to find some
Incidentally, all these places where rmap is used by the core VM were
introduced in 2.5.27 as well. In particular vmscan.c was completely
overhauled. But apparently you suspect subsequent changes to the core
to be a problem. I am curious what they are if that can help fixing
the slowdowns I'm seeing.
Roger
^ permalink raw reply
* Re: Alsa sequencer port type flags
From: Clemens Ladisch @ 2003-12-11 10:18 UTC (permalink / raw)
To: David Garcia Garzon; +Cc: alsa-devel
In-Reply-To: <200312101335.39428.dgarcia@iua.upf.es>
David Garcia Garzon wrote:
> SND_SEQ_PORT_TYPE_SPECIFIC Hardware specific port
something hardware-specific (obviously :-)
> SND_SEQ_PORT_TYPE_MIDI_GENERIC Generic MIDI device
Understands MIDI events/commands.
> SND_SEQ_PORT_TYPE_MIDI_GM General MIDI compatible device
> SND_SEQ_PORT_TYPE_MIDI_GS GS compatible device
> SND_SEQ_PORT_TYPE_MIDI_XG XG compatible device
> SND_SEQ_PORT_TYPE_MIDI_MT32 MT-32 compatible device
Support for these standards. Not necessarily full support, and the
availability of instruments may depend on loaded soundfonts, but basic
things like bank selection and drum channel selection should work.
This is not set for external ports like MPU-401 which may have a
compatible device connected to them.
> SND_SEQ_PORT_TYPE_SYNTH Synth device
Device can playback sound via the SAMPLE_* events. (The OPL3 driver
sets this flag too, so either this driver or my description is wrong.)
> SND_SEQ_PORT_TYPE_DIRECT_SAMPLE Sampling device (supporting download)
Can download instrument samples (SND_SEQ_EVENT_INSTR_PUT etc.)
> SND_SEQ_PORT_TYPE_SAMPLE Sampling device (sample can be downloaded at any time)
No ALSA driver sets this. I don't know what "at any time" means; the
INSTR_* events _can_ be sent at any time.
> SND_SEQ_PORT_TYPE_APPLICATION Application (sequencer/editor)
This port is (usually) controlled by the user, and not by events sent
to it.
> But which are the implications of setting up a port with such flags?
> - Are they merely informative?
Yes.
> - Will Alsa coerce or enhance the port usage depending on that type?
No. ALSA never looks at these flags, except when someone wants to
read port information.
> - Can the user see that information in any way?
It isn't even shown in the proc files AFAIK.
> What is the use, in a programmer view, of alsa sequencer port type
> flags?
Not much. They're more or less useless for automatic selection/
filtering of ports. It may be possible to show them to the user, but
they won't be accurate in every case.
HTH
Clemens
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply
* OOPS: test11, VIA VT8601 gcc 3.3.2
From: Joost Witteveen @ 2003-12-11 10:16 UTC (permalink / raw)
To: linux-kernel
The 2.6.0test11 is running rather unstable here; it's halted
for no reason several times already (no network, keyboard hangs,
and no graphics output (monitor says "No Signal"), usually
after a couple of days of uptime. Each time there was no
trace to be found in /var/log/*, but this time there was.
I was doing `nothign' with the computer, the last thing before
the oops I could find in /var/log/syslog were: some dhclient
00:21:10: dhclient: No DHCPOFFERS received.
00:21:23: sendmail recieving email
00:22:02: cron starting a perl script, connects to mysql
00:22:36: sendmail again
00:23:01: cron testing for existance of file
So, basically, linux was doing nothing at 00:23:18
I remember reading that 2.6 shouldn't be compiled with gcc 3.3,
which I did, but I hope that eighter my oops doesn't relate to
gcc, or, that my oops may help linux be compiled with 3.3
ksymoops 2.4.9 on i686 2.6.0-test11. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.6.0-test11/ (default)
-m /boot/System.map-2.6.0-test11 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Dec 11 00:23:18 foko kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Dec 11 00:23:18 foko kernel: c0117839
Dec 11 00:23:18 foko kernel: *pde = 00000000
Dec 11 00:23:18 foko kernel: Oops: 0002 [#1]
Dec 11 00:23:18 foko kernel: CPU: 0
Dec 11 00:23:18 foko kernel: EIP: 0060:[<c0117839>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
Dec 11 00:23:18 foko kernel: EFLAGS: 00010097
Dec 11 00:23:18 foko kernel: eax: 00000001 ebx: cb540cc0 ecx: cb540ce0 edx: 0d8ea388
Dec 11 00:23:18 foko kernel: esi: 00000000 edi: daabfd20 ebp: daabfcbc esp: daabfc78
Dec 11 00:23:18 foko kernel: ds: 007b es: 007b ss: 0068
Dec 11 00:23:18 foko kernel: Stack: c4ef1210 c732ac00 00000003 daabfcc8 c03324b0 00000002 df791900 dc906480
Dec 11 00:23:18 foko kernel: 00000000 cb5412e0 cb541300 000010e1 0d8eb469 000024a9 00000000 7fffffff
Dec 11 00:23:18 foko kernel: daabfd20 daabfcf8 c012371d 00000000 daabfdc0 c034ee87 c732ac00 c0331550
Dec 11 00:23:18 foko kernel: Call Trace:
Dec 11 00:23:18 foko kernel: [<c03324b0>] ip_push_pending_frames+0x3a0/0x400
Dec 11 00:23:18 foko kernel: [<c012371d>] schedule_timeout+0xad/0xb0
Dec 11 00:23:18 foko kernel: [<c034ee87>] raw_sendmsg+0x397/0x580
Dec 11 00:23:18 foko kernel: [<c0331550>] ip_generic_getfrag+0x0/0xc0
Dec 11 00:23:18 foko kernel: [<c0318380>] wait_for_packet+0xb0/0x110
Dec 11 00:23:18 foko kernel: [<c0119400>] autoremove_wake_function+0x0/0x50
Dec 11 00:23:18 foko kernel: [<c0119400>] autoremove_wake_function+0x0/0x50
Dec 11 00:23:18 foko kernel: [<c031847b>] skb_recv_datagram+0x9b/0x100
Dec 11 00:23:18 foko kernel: [<c034f1f7>] raw_recvmsg+0x67/0x170
Dec 11 00:23:18 foko kernel: [<c0358fa4>] inet_recvmsg+0x54/0x70
Dec 11 00:23:18 foko kernel: [<c0312a05>] sock_recvmsg+0x95/0xb0
Dec 11 00:23:18 foko kernel: [<c0168883>] update_atime+0x93/0xe0
Dec 11 00:23:18 foko kernel: [<c01375fb>] __alloc_pages+0xab/0x350
Dec 11 00:23:18 foko kernel: [<c03126fa>] sockfd_lookup+0x1a/0x80
Dec 11 00:23:18 foko kernel: [<c0313eb4>] sys_recvfrom+0x94/0x100
Dec 11 00:23:18 foko kernel: [<c0115fe0>] do_page_fault+0x360/0x57e
Dec 11 00:23:18 foko kernel: [<c0314803>] sys_socketcall+0x1d3/0x290
Dec 11 00:23:18 foko kernel: [<c012358b>] sys_alarm+0x3b/0x50
Dec 11 00:23:18 foko kernel: [<c010953b>] syscall_call+0x7/0xb
Dec 11 00:23:18 foko kernel: Code: ff 0e 8b 51 04 8b 43 20 89 50 04 89 02 c7 41 04 00 02 20 00
>>EIP; c0117839 <schedule+f9/590> <=====
>>ebx; cb540cc0 <_end+b068778/3fb25ab8>
>>ecx; cb540ce0 <_end+b068798/3fb25ab8>
>>edi; daabfd20 <_end+1a5e77d8/3fb25ab8>
>>ebp; daabfcbc <_end+1a5e7774/3fb25ab8>
>>esp; daabfc78 <_end+1a5e7730/3fb25ab8>
Trace; c03324b0 <ip_push_pending_frames+3a0/400>
Trace; c012371d <schedule_timeout+ad/b0>
Trace; c034ee87 <raw_sendmsg+397/580>
Trace; c0331550 <ip_generic_getfrag+0/c0>
Trace; c0318380 <wait_for_packet+b0/110>
Trace; c0119400 <autoremove_wake_function+0/50>
Trace; c0119400 <autoremove_wake_function+0/50>
Trace; c031847b <skb_recv_datagram+9b/100>
Trace; c034f1f7 <raw_recvmsg+67/170>
Trace; c0358fa4 <inet_recvmsg+54/70>
Trace; c0312a05 <sock_recvmsg+95/b0>
Trace; c0168883 <update_atime+93/e0>
Trace; c01375fb <__alloc_pages+ab/350>
Trace; c03126fa <sockfd_lookup+1a/80>
Trace; c0313eb4 <sys_recvfrom+94/100>
Trace; c0115fe0 <do_page_fault+360/57e>
Trace; c0314803 <sys_socketcall+1d3/290>
Trace; c012358b <sys_alarm+3b/50>
Trace; c010953b <syscall_call+7/b>
Code; c0117839 <schedule+f9/590>
00000000 <_EIP>:
Code; c0117839 <schedule+f9/590> <=====
0: ff 0e decl (%esi) <=====
Code; c011783b <schedule+fb/590>
2: 8b 51 04 mov 0x4(%ecx),%edx
Code; c011783e <schedule+fe/590>
5: 8b 43 20 mov 0x20(%ebx),%eax
Code; c0117841 <schedule+101/590>
8: 89 50 04 mov %edx,0x4(%eax)
Code; c0117844 <schedule+104/590>
b: 89 02 mov %eax,(%edx)
Code; c0117846 <schedule+106/590>
d: c7 41 04 00 02 20 00 movl $0x200200,0x4(%ecx)
Dec 11 00:23:18 foko kernel: Call Trace:
Dec 11 00:23:18 foko kernel: [<c0117cc5>] schedule+0x585/0x590
Dec 11 00:23:18 foko kernel: [<c013fb0e>] unmap_page_range+0x4e/0x80
Dec 11 00:23:18 foko kernel: [<c013fd08>] unmap_vmas+0x1c8/0x220
Dec 11 00:23:18 foko kernel: [<c0143a38>] exit_mmap+0x78/0x190
Dec 11 00:23:18 foko kernel: [<c01196b6>] mmput+0x66/0xc0
Dec 11 00:23:18 foko kernel: [<c011d5f8>] do_exit+0x118/0x3d0
Dec 11 00:23:18 foko kernel: [<c0115c80>] do_page_fault+0x0/0x57e
Dec 11 00:23:18 foko kernel: [<c0109e01>] die+0xe1/0xf0
Dec 11 00:23:18 foko kernel: [<c0115e7c>] do_page_fault+0x1fc/0x57e
Dec 11 00:23:18 foko kernel: [<c0332a80>] ip_finish_output2+0xc0/0x1b0
Dec 11 00:23:18 foko kernel: [<c032537d>] nf_hook_slow+0xed/0x140
Dec 11 00:23:18 foko kernel: [<c03329c0>] ip_finish_output2+0x0/0x1b0
Dec 11 00:23:18 foko kernel: [<c03305f5>] ip_finish_output+0x205/0x210
Dec 11 00:23:18 foko kernel: [<c03329c0>] ip_finish_output2+0x0/0x1b0
Dec 11 00:23:18 foko kernel: [<c0115c80>] do_page_fault+0x0/0x57e
Dec 11 00:23:18 foko kernel: [<c0109745>] error_code+0x2d/0x38
Dec 11 00:23:18 foko kernel: [<c0117839>] schedule+0xf9/0x590
Dec 11 00:23:18 foko kernel: [<c03324b0>] ip_push_pending_frames+0x3a0/0x400
Dec 11 00:23:18 foko kernel: [<c012371d>] schedule_timeout+0xad/0xb0
Dec 11 00:23:18 foko kernel: [<c034ee87>] raw_sendmsg+0x397/0x580
Dec 11 00:23:18 foko kernel: [<c0331550>] ip_generic_getfrag+0x0/0xc0
Dec 11 00:23:18 foko kernel: [<c0318380>] wait_for_packet+0xb0/0x110
Dec 11 00:23:18 foko kernel: [<c0119400>] autoremove_wake_function+0x0/0x50
Dec 11 00:23:18 foko kernel: [<c0119400>] autoremove_wake_function+0x0/0x50
Dec 11 00:23:18 foko kernel: [<c031847b>] skb_recv_datagram+0x9b/0x100
Dec 11 00:23:18 foko kernel: [<c034f1f7>] raw_recvmsg+0x67/0x170
Dec 11 00:23:18 foko kernel: [<c0358fa4>] inet_recvmsg+0x54/0x70
Dec 11 00:23:18 foko kernel: [<c0312a05>] sock_recvmsg+0x95/0xb0
Dec 11 00:23:18 foko kernel: [<c0168883>] update_atime+0x93/0xe0
Dec 11 00:23:18 foko kernel: [<c01375fb>] __alloc_pages+0xab/0x350
Dec 11 00:23:18 foko kernel: [<c03126fa>] sockfd_lookup+0x1a/0x80
Dec 11 00:23:18 foko kernel: [<c0313eb4>] sys_recvfrom+0x94/0x100
Dec 11 00:23:18 foko kernel: [<c0115fe0>] do_page_fault+0x360/0x57e
Dec 11 00:23:18 foko kernel: [<c0314803>] sys_socketcall+0x1d3/0x290
Dec 11 00:23:18 foko kernel: [<c012358b>] sys_alarm+0x3b/0x50
Dec 11 00:23:18 foko kernel: [<c010953b>] syscall_call+0x7/0xb
Warning (Oops_read): Code line not seen, dumping what data is available
Trace; c0117cc5 <schedule+585/590>
Trace; c013fb0e <unmap_page_range+4e/80>
Trace; c013fd08 <unmap_vmas+1c8/220>
Trace; c0143a38 <exit_mmap+78/190>
Trace; c01196b6 <mmput+66/c0>
Trace; c011d5f8 <do_exit+118/3d0>
Trace; c0115c80 <do_page_fault+0/57e>
Trace; c0109e01 <die+e1/f0>
Trace; c0115e7c <do_page_fault+1fc/57e>
Trace; c0332a80 <ip_finish_output2+c0/1b0>
Trace; c032537d <nf_hook_slow+ed/140>
Trace; c03329c0 <ip_finish_output2+0/1b0>
Trace; c03305f5 <ip_finish_output+205/210>
Trace; c03329c0 <ip_finish_output2+0/1b0>
Trace; c0115c80 <do_page_fault+0/57e>
Trace; c0109745 <error_code+2d/38>
Trace; c0117839 <schedule+f9/590>
Trace; c03324b0 <ip_push_pending_frames+3a0/400>
Trace; c012371d <schedule_timeout+ad/b0>
Trace; c034ee87 <raw_sendmsg+397/580>
Trace; c0331550 <ip_generic_getfrag+0/c0>
Trace; c0318380 <wait_for_packet+b0/110>
Trace; c0119400 <autoremove_wake_function+0/50>
Trace; c0119400 <autoremove_wake_function+0/50>
Trace; c031847b <skb_recv_datagram+9b/100>
Trace; c034f1f7 <raw_recvmsg+67/170>
Trace; c0358fa4 <inet_recvmsg+54/70>
Trace; c0312a05 <sock_recvmsg+95/b0>
Trace; c0168883 <update_atime+93/e0>
Trace; c01375fb <__alloc_pages+ab/350>
Trace; c03126fa <sockfd_lookup+1a/80>
Trace; c0313eb4 <sys_recvfrom+94/100>
Trace; c0115fe0 <do_page_fault+360/57e>
Trace; c0314803 <sys_socketcall+1d3/290>
Trace; c012358b <sys_alarm+3b/50>
Trace; c010953b <syscall_call+7/b>
2 warnings and 1 error issued. Results may not be reliable.
$ cat /proc/version
Linux version 2.6.0-test11 (joostje@foko) (gcc version 3.3.2 (Debian)) #2 Wed Dec 3 23:12:38 CET 2003
$ lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia] (rev 05)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a)
00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a)
00:07.4 Class 0080: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50)
00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C (rev 10)
01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 6a)
$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 hdc5[1] hdb5[0]
16865728 blocks [2/2] [UU]
^ permalink raw reply
* [PATCH] Polish FAQ update
From: Maciej Soltysiak @ 2003-12-11 10:15 UTC (permalink / raw)
To: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 3289 bytes --]
Hi,
this patch fixes my screwups with the translation.
Also I'd like to point out, that there is a problem with
sgmltools and linuxdoc-tools. They both have has bad translations of
polish words for:
Next, Previous, Index
They have:
Nastny, Poprzedni, Spis Trei
instead of:
Następny, Poprzedni, Spis Treści
I have just sent the patch to the maintainer of Lang.pm.
You might want to patch your
/usr/share/linuxdoc-tools/LinuxDocTools/Lang.pm
(or whatever the path is for Lang.pm)
with the Lang.pm.diff patch.
I can't belive it hasn't been fixed yet. I have noticed it about 1,5 year
ago :-|
Okay, here they go: FAQ patch, Lang.pm patch.
Index: documentation/FAQ/pl/netfilter-faq.sgml
===================================================================
RCS file: /cvspublic/netfilter/documentation/FAQ/pl/netfilter-faq.sgml,v
retrieving revision 1.8
diff -u -r1.8 netfilter-faq.sgml
--- documentation/FAQ/pl/netfilter-faq.sgml 16 Oct 2003 07:36:38 -0000 1.8
+++ documentation/FAQ/pl/netfilter-faq.sgml 11 Dec 2003 10:03:45 -0000
@@ -4,10 +4,8 @@
<title>netfilter/iptables FAQ</title>
<author>Harald Welte <laforge@gnumonks.org>&nl;
-<date>Version $Revision: 1.8 $, $Date: 2003/10/16 07:36:38 $</date>
+<date>Version $Revision: 1.9 $, $Date: 2003/12/11 10:55:39 $</date>
Tłumaczenie: Maciej Sołtysiak<tt><htmlurl name="solt@dns.toxicfilms.tv"
url="mailto:solt@dns.toxicfilms.tv"></tt></author>
-<date>Version $Revision: 1.8 $, $Date: 2003/10/16 07:36:38 $</date>
-Tłumaczenie: Środa 15 Października 2003 $</date>
<abstract>
Ten dokument zawiera najczęściej zadawane pytania (Frequently Asked
Questions) występujące na liście
@@ -123,8 +121,6 @@
jest w iptables. Zerknij w NAT HOWTO na stronach domowych netfiltra.
</sect1>
-</sect>
-
<sect1>Czy iptables/ip6tables jest w stanie zrobić IPv6 NAT?
<p>
Nie, rdzeń NAT nie obsługuje transjacji IPv6 lub IPv6/IPv4 jakiegokolwiek
@@ -144,8 +140,6 @@
</sect1>
<sect1>Czy netfilter/iptables wspiera failover/HA?
-
-Does netfilter/iptables support failover/HA?
<p>
Odpowiedź jest prosta 'tak' i 'nie'.
<p>
@@ -159,7 +153,7 @@
<p>Jeśli chcesz przechować połączenia NAT: <bf>Nie</bf>.
<p>Jeśli filtrujesz bez przechowywania stanu (stateless): <bf>Tak</bf>
</sect1>
-
+</sect>
<sect>Problemy podczas kompilacji
@@ -280,9 +274,7 @@
<tscreen><verb>
ip_conntrack: max number of expected connections N of M reached for
aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
</verb></tscreen>
-</sect1>
-<sect1>
<p>
Zasadniczo nie ma się czym przejmować, szczególnie gdy <tt>N</tt> i
<tt>M</tt> sa <tt>1</tt>, a po tej wiadomości jest <tt>, reusing</tt>.
--- Lang.pm~ 2002-03-25 14:46:40.000000000 +0100
+++ Lang.pm 2003-12-11 11:07:41.000000000 +0100
@@ -185,7 +185,7 @@
"it" => "Avanti",
"ro" => "Înainte",
"ja" => "źĄ¤ÎĽÚĄźĽ¸",
- "pl" => "Nastny",
+ "pl" => "Następny",
"ko" => "´ŮŔ˝"
},
"Contents" => {
@@ -201,7 +201,7 @@
"it" => "Indice",
"ro" => "Cuprins",
"ja" => "ĚÜźĄ¤Ř",
- "pl" => "Spis Trei",
+ "pl" => "Spis Treści",
"ko" => "Â÷ˇĘ"
},
"Table of Contents" => {
@@ -217,7 +217,7 @@
"it" => "Indice Generale",
"ro" => "Cuprins",
"ja" => "ĚÜźĄ",
- "pl" => "Spis Trei",
+ "pl" => "Spis Treści",
"ko" => "Â÷ˇĘ"
}
};
[-- Attachment #2: Lang.pm.diff --]
[-- Type: application/octet-stream, Size: 709 bytes --]
--- Lang.pm~ 2002-03-25 14:46:40.000000000 +0100
+++ Lang.pm 2003-12-11 11:07:41.000000000 +0100
@@ -185,7 +185,7 @@
"it" => "Avanti",
"ro" => "Înainte",
"ja" => "¼¡¤Î¥Ú¡¼¥¸",
- "pl" => "Nastny",
+ "pl" => "Nastêpny",
"ko" => "´ÙÀ½"
},
"Contents" => {
@@ -201,7 +201,7 @@
"it" => "Indice",
"ro" => "Cuprins",
"ja" => "Ìܼ¡¤Ø",
- "pl" => "Spis Trei",
+ "pl" => "Spis Tre¶ci",
"ko" => "Â÷·Ê"
},
"Table of Contents" => {
@@ -217,7 +217,7 @@
"it" => "Indice Generale",
"ro" => "Cuprins",
"ja" => "Ìܼ¡",
- "pl" => "Spis Trei",
+ "pl" => "Spis Tre¶ci",
"ko" => "Â÷·Ê"
}
};
[-- Attachment #3: faq.diff --]
[-- Type: application/octet-stream, Size: 2029 bytes --]
Index: documentation/FAQ/pl/netfilter-faq.sgml
===================================================================
RCS file: /cvspublic/netfilter/documentation/FAQ/pl/netfilter-faq.sgml,v
retrieving revision 1.8
diff -u -r1.8 netfilter-faq.sgml
--- documentation/FAQ/pl/netfilter-faq.sgml 16 Oct 2003 07:36:38 -0000 1.8
+++ documentation/FAQ/pl/netfilter-faq.sgml 11 Dec 2003 10:03:45 -0000
@@ -4,10 +4,8 @@
<title>netfilter/iptables FAQ</title>
<author>Harald Welte <laforge@gnumonks.org>&nl;
-<date>Version $Revision: 1.8 $, $Date: 2003/10/16 07:36:38 $</date>
+<date>Version $Revision: 1.9 $, $Date: 2003/12/11 10:55:39 $</date>
T³umaczenie: Maciej So³tysiak<tt><htmlurl name="solt@dns.toxicfilms.tv" url="mailto:solt@dns.toxicfilms.tv"></tt></author>
-<date>Version $Revision: 1.8 $, $Date: 2003/10/16 07:36:38 $</date>
-T³umaczenie: ¦roda 15 Pa¼dziernika 2003 $</date>
<abstract>
Ten dokument zawiera najczê¶ciej zadawane pytania (Frequently Asked Questions) wystêpuj±ce na li¶cie
@@ -123,8 +121,6 @@
jest w iptables. Zerknij w NAT HOWTO na stronach domowych netfiltra.
</sect1>
-</sect>
-
<sect1>Czy iptables/ip6tables jest w stanie zrobiæ IPv6 NAT?
<p>
Nie, rdzeñ NAT nie obs³uguje transjacji IPv6 lub IPv6/IPv4 jakiegokolwiek
@@ -144,8 +140,6 @@
</sect1>
<sect1>Czy netfilter/iptables wspiera failover/HA?
-
-Does netfilter/iptables support failover/HA?
<p>
Odpowied¼ jest prosta 'tak' i 'nie'.
<p>
@@ -159,7 +153,7 @@
<p>Je¶li chcesz przechowaæ po³±czenia NAT: <bf>Nie</bf>.
<p>Je¶li filtrujesz bez przechowywania stanu (stateless): <bf>Tak</bf>
</sect1>
-
+</sect>
<sect>Problemy podczas kompilacji
@@ -280,9 +274,7 @@
<tscreen><verb>
ip_conntrack: max number of expected connections N of M reached for aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
</verb></tscreen>
-</sect1>
-<sect1>
<p>
Zasadniczo nie ma siê czym przejmowaæ, szczególnie gdy <tt>N</tt> i
<tt>M</tt> sa <tt>1</tt>, a po tej wiadomo¶ci jest <tt>, reusing</tt>.
^ permalink raw reply
* Re: udev sysfs docs Re: State of devfs in 2.6?
From: Måns Rullgård @ 2003-12-11 10:15 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1071134837.1789.123.camel@nomade>
Xavier Bestel <xavier.bestel@free.fr> writes:
> Le mer 10/12/2003 à 21:06, Witukind a écrit :
>> On Wed, 10 Dec 2003 08:02:46 +0100
>> Xavier Bestel <xavier.bestel@free.fr> wrote:
>> > Come on ... the stock kernel from your distribution will do the
>> > modprobe for you when you access the floppy, I'm sure you're skilled
>> > enough to configure your own kernel to do the same.
>> > And if you don't want to recompile, just chmod +s modprobe - on your
>> > small machine which needs to save 60k, I bet you're the only user. Or
>> > use sudo.
>> >
>> > Xav
>>
>> I was expecting this kind of reply. Like "if you have an older hardware you
>> can fuck off".
>
> Wow ... how can you understand this in my text ? Because I'm guessing he
> is the only user on his machine ? This has nothing to do with small
> machines, but with system configuration: load on-demand may be done
> without devfs.
It certainly can be done without devfs. I was objecting to the udev
way of thinking that all drivers are always loaded. If you want to
use udev and on-demand loading, you need to do some tweaking.
> Well, I wish do apologize to Måns if he thought I was ridiculing his
> hardware. Just take out the last sentence with "modprobe" if it bothers
> you.
Well, my hardware is as good as any.
--
Måns Rullgård
mru@kth.se
^ permalink raw reply
* Re: Brigde and Firewall with linux
From: ONeill Jack @ 2003-12-11 10:14 UTC (permalink / raw)
To: Cedric Blancher, Luca Scattin; +Cc: netfilter
In-Reply-To: <1071132494.781.19.camel@elendil.intranet.cartel-securite.net>
--- Cedric Blancher <blancher@cartel-securite.fr> a
écrit :
> On 2.6 kernels, output interface will be br0, not
> eth0. So you'll have
> to use physdev match in order to have your rule work
> :
> iptables -t nat -A POSTROUTING -m physdev
> --physdev-out eth1 \
> -j SNAT --to 192.168.0.21
>
> I don't know if this behaviour has been backported
> to 2.4 kernels. At
> least, you can try ;)
I thought you could only use the FORWARD CHAIN when
it's a bridge, because a bridge only passes packets
from one interface to another (?)
_________________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
^ permalink raw reply
* Re: Driver API (was Re: Linux GPL and binary module exception clause?)
From: viro @ 2003-12-11 10:06 UTC (permalink / raw)
To: Hannu Savolainen
Cc: Linus Torvalds, Larry McVoy, Andre Hedrick, Arjan van de Ven,
Valdis.Kletnieks, Kendall Bennett, linux-kernel
In-Reply-To: <Pine.LNX.4.58.0312102256520.3787@zeus.compusonic.fi>
On Thu, Dec 11, 2003 at 02:50:20AM +0200, Hannu Savolainen wrote:
> Even better would be a proper device driver ABI for "loosely integrated"
> device drivers. It's possible to hide differences between kernel releases
> so that the same driver can work with wide range of kernel versions).
> There are some performance penalties but they are not significant. And the
> drivers included in the kernel source tree don't need to use this
> interface so I don't see there any _technical_ reasons against this idea.
> I can volunteer to implement this interface if it's OK. Some motivation
> for the ABI as well as some technical ideas will be at the end of this
> message.
It doesn't work. Let me give you an example: right now we have a way to get
from struct inode to struct block device - inode->i_bdev. You can wrap it
into helper functions, whatever - it won't live to 2.8.
Why? Because if we want to handle device removal in a sane way, that
association will have to go. We will still have a need (and a way) to get
from opened struct file of block device to its struct block_device. And _that_
association will remain stable through the entire life of struct file. Even
when the mapping from inode to block device gets changed.
And it means that arguments of block device ->open(), ->release() and
->ioctl() will change - instead of struct inode we will pass the struct
block_device directly. It's OK - callers have a way to get the thing and
methods themselves... right now the first thing they do is
struct block_device *bdev = inode->i_bdev;
and either don't use inode afterwards at all or (very few) use it in a way
that can be replaced with use of bdev (e.g. inode->i_rdev -> bdev->bd_dev,
etc.). The sole exception (floppy.c) still can get what it wants from the
second argument of ->open() (struct file *).
The rest of the tree also can deal - I've done that and patches are
in -mm right now. Most of them are easily mergable in 2.6, BTW.
See what it means? No fscking way to deal with that in wrappers.
Simply because the old assumption (inode->block_device remains stable)
is flat out wrong with new kernel. Note that "just add a new API and leave
the old one for old drivers" would *NOT* work here.
And yes, it's an interface change. Caused by the fact that old
interface is Wrong(tm) (BTW, large part of that one is my fault - design
mistake in 2.3 that hadn't become obvious until 2.5.late). Sure, we can
declare the new variant a part of ABI and have the glue for 2.4 and 2.6
wrap the new ->open()/->ioctl()/->release() with boilerplate that will
produce old-style ones. _That_ direction is easy. But that won't help
you with ABI - it allows to put new driver into old kernel, not the other
way round. Which, come to think of it, is hardly a surprise - hindsight
is always 20/20 and all such.
There is a good measure of interface quality - the less boilerplate
code you need to use it, the better. It's not a trivial observation and
not just a matter of aesthetics. It also means that there's less chance
of non-trivial breakage. Note that you can wrap a good interface into bad
one - and that can usually be done in a uniform way (i.e. by _adding_ that
boilerplate code). You can't go the other way round. Case above is a good
example of that effect.
See the problem now? We can keep the same payload code if it uses
a good interface and we add wrappers to make it work with kernels that give
worse interfaces. So if we design a really good one, we can say "that's our
ABI" and... what, exactly? As long as new kernels have interfaces that are
not better than our, we are OK. But it simply means that
a) we should just use that good interface (and no glue) as kernel one.
b) as soon as we have a need to improve the kernel interface, no amount
of glue is going to save that "ABI".
c) in case if we decide to make kernel interface *WORSE*, our ABI will
really shine - then we will simply add glue to deal with degraded kernel.
Which leaves only one question - why in damnation name would we ever
go for the case (c)?
In other words, the nature of interface changes is such that usually
you can do glue between old interface and new driver and not the other way
round. Which kills ABI idea - either you get a particular interface 100%
right and no glue is needed (then interface never changes simply because it's
Right(tm) and needs no changes) or you do not and no glue will save you as
soon as change becomes necessary.
I'm a fairly arrogant bastard, but I do *not* claim that I can do
all interfaces right at once and avoid design mistakes. Do you? And if
yes, where can I get the drugs you are on?
^ permalink raw reply
* Re: is it possible only with iptables
From: Antony Stone @ 2003-12-11 10:05 UTC (permalink / raw)
To: netfilter
In-Reply-To: <200312101928.27882.petre@kgb.ro>
On Wednesday 10 December 2003 5:28 pm, Petre Bandac wrote:
> I have 2 linux machines - linux_1 and linux_2
>
> linux_1 has behind it a subnet with routable adresses (not private)
>
> I want that all the traffic incoming from the subnet behind linux_1 and
> going to port 80 to be redirected to linux_2, and from linux_2 go on the
> internet
>
> I presumed that a -j SNAT --to-source IP_linux_2 should be enough, but
> apparently it isn't
If you want to redirect packets which would normally go somewhere else, so
that they go to machine linux_2 instead, this is either DNAT, or a routing
table question (using something slightly more sophisticated than usual, such
as source-based routing and iproute2).
DNAT will clearly send the packets to linux_2 for you, but then they won't go
any further, because they've reached their destination.
> should I issue a SNAT rule on linux_2 too, or it should run something like
> squid there ?
Maybe you should run something like squid there - tell us why you want the
port 80 packets specifically to go via linux_2 rather than any other route
from linux_1 to the Internet....
Antony.
--
Most people are aware that the Universe is big.
- Paul Davies, Professor of Theoretical Physics
Please reply to the list;
please don't CC me.
^ permalink raw reply
* UCD-SNMP 4.2.1 and SNMP v3
From: llandre @ 2003-12-11 10:03 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I tried to run the snmpd daemon of UCD-SNMP 4.2.1 on a PPC405EP-based
system equipped with Linux 2.4.20. I built the package directly on the
target (no cross compilation) with the ELDK 2.0.2. The version of the
openssl libraries is 0.9.6b-8. Everything works fine with v1 and v2
operations but I have authentication problems with the v3 operations. The
same daemon, with the same configuration files, works fine on a PC (Red Hat
7.2).
Here is the snippet of the dump:
dumpv_recv: String:
trace: sc_hash(): scapi.c, 328
trace: sc_get_properlength(): scapi.c, 81
trace: get_enginetime(): lcd_time.c, 152
lcd_get_enginetime: engineID 80 00 07 E5 80 11 65 9F 88 00 00 0F 37 :
boots=15, time=10
trace: usm_get_user(): snmpusm.c, 2553
usm: getting user mtek
trace: sc_check_keyed_hash(): scapi.c, 408
sc_check_keyed_hash(): key=0x73b5f6979b89bf1ef0ebec2cf7e9a80e (16)
trace: sc_generate_keyed_hash(): scapi.c, 218
trace: sc_get_properlength(): scapi.c, 81
trace: usm_process_in_msg(): snmpusm.c, 2244
usm: Verification failed.
trace: snmpv3_parse(): snmp_api.c, 2953
dumph_recv: ScopedPDU
trace: snmpv3_scopedPDU_parse(): snmp_api.c, 3577
dumph_recv: contextEngineID
dumpx_recv: 04 0D 80 00 07 E5 80 11 65 9F 88 00 00 0F 37
dumpv_recv: String: ......e.....7
trace: snmpv3_scopedPDU_parse(): snmp_api.c, 3599
dumph_recv: contextName
dumpx_recv: 04 00
dumpv_recv: String:
trace: snmpv3_parse(): snmp_api.c, 2958
dumph_recv: PDU-GET
trace: snmp_pdu_parse(): snmp_api.c, 3385
dumph_recv: request_id
dumpx_recv: 02 04 41 4C 9C F6
The key calculated by the sc_check_keyed_hash function is to the one I read
in the /var/ucd-snmp/snmpd.conf.
I suspect the problem is referred to either the PPC architecture (missing a
compiler flag?) or the openssl libraries.
Anybody can help me?
Thanx in advance,
llandre
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: ALSA mixing capability
From: Jaroslav Kysela @ 2003-12-11 10:01 UTC (permalink / raw)
To: Adam Tla/lka; +Cc: alsa-devel
In-Reply-To: <3FD83DC2.6090502@pg.gda.pl>
On Thu, 11 Dec 2003, Adam Tla/lka wrote:
> Welcome
>
> I'm using ALSA 1.0.0rc2 on snd_intel8x0 and .asoundrc:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> pcm.mix {
> type dmix
> ipc_key 321456 # any unique value
> ipc_key_add_uid true
> slave {
> pcm "hw:0,0"
> periods 0
> period_time 0
> period_size 1024 # must be power of 2
> buffer_size 4096 # ditto
> }
> bindings {
> 0 0
> 1 1
> }
> }
> ctl.mix { type hw card 0 }
> pcm.dsp0 { type plug slave.pcm "mix" }
> ctl.mixer0 { type hw card 0 }
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> My problem:
>
> when using wavplay with OSS ALSA emulation playing 22050 and 11025 Hz
> .wav files works OK
> but with AOSS lib using pcm.dsp0 defined above I can't play 11025 Hz
> .wav file:
>
> $ aoss wavplay lburn2.wav
> Pathname: lburn2.wav
> Device: /dev/dsp
> Sampling Rate: 11025 Hz
> Mode: Mono
> Samples: 5999
> Bits: 8
>
> Unable to set audio sampling rate
>
> but 22050 HZ .wav is played correctly.
>
> So my question is how properly compose .asoundrc file so we could mix
> all sound sources which use ALSA natively
> through -Dmix virtual device and OSS apps routed through AOSS lib? Is
> this possible? Is this explained somewhere?
If you use mostly 44.1kHz material (or multiple of this rate), then
explicitly set the 44.1kHz rate in pcm.dmix section (rate 44100). Note
that your hardware must support this rate.
Anyway, it seems like a bug.
> Next case is a possibility to create a virtual mixer so ctl.mix
> virtually sets level of particular source before mixing
> it with others sources so playind applications could set volumen of only
> his source. Is that possible?
I know about this problem and it will be fixed one day.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply
* Re: DNS with iptables
From: Antony Stone @ 2003-12-11 9:59 UTC (permalink / raw)
To: netfilter
In-Reply-To: <4D365C260C742A4AABFBF2EE41B7E59F312D8D@itfbsv01.itservices.intern>
On Friday 05 December 2003 2:31 pm, Centkowski, Peter (SSFB) wrote:
> Helo
220 :)
> Kann ich statt IP-Adresse auch ein Name in Iptables verwenden?
Yes, you can use both hostnames and IP addresses in netfilter rules, however
any hostnames are resolved to an address only once, when you put the rule in.
You cannot get netfilter to resolve names every time it sees a packet, for
example.
> Es geht um Dyndns und damit einem Problem...
Ja, das ist ein Problem :(
Viele Grüße
Antony.
--
The difference between theory and practice is that in theory there is no
difference, whereas in practice there is.
Please reply to the list;
please don't CC me.
^ permalink raw reply
* Re: ia64 atomic_dec_and_lock() patch
From: jerome.marchand @ 2003-12-11 9:58 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-107107082810707@msgid-missing>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2490 bytes --]
On Wed, 10 Dec 2003, David Mosberger wrote:
> Could you try replacing the inline-asm with cmpxchg() function? That
> way, you won't break compilation with Intel's compiler.
OK, here's the new patch.
I also join the right patch for lockmeter.
diff -urN linux-2.6.0-test11.orig/arch/ia64/Kconfig
linux-2.6.0-test11/arch/ia64/Kconfig
--- linux-2.6.0-test11.orig/arch/ia64/Kconfig 2003-12-09
11:26:58.000000000 +0100
+++ linux-2.6.0-test11/arch/ia64/Kconfig 2003-12-09
11:34:09.000000000 +0100
@@ -375,6 +375,11 @@
depends on IA32_SUPPORT
default y
+config HAVE_DEC_LOCK
+ bool
+ depends on (SMP || PREEMPT)
+ default y
+
config PERFMON
bool "Performance monitor support"
help
diff -urN linux-2.6.0-test11.orig/arch/ia64/lib/Makefile
linux-2.6.0-test11/arch/ia64/lib/Makefile
--- linux-2.6.0-test11.orig/arch/ia64/lib/Makefile 2003-12-09
11:26:58.000000000 +0100
+++ linux-2.6.0-test11/arch/ia64/lib/Makefile 2003-12-09
11:32:05.000000000 +0100
@@ -13,6 +13,7 @@
lib-$(CONFIG_MCKINLEY) += copy_page_mck.o memcpy_mck.o
lib-$(CONFIG_PERFMON) += carta_random.o
lib-$(CONFIG_MD_RAID5) += xor.o
+lib-$(CONFIG_HAVE_DEC_LOCK) += dec_and_lock.o
AFLAGS___divdi3.o =
AFLAGS___udivdi3.o = -DUNSIGNED
diff -urN linux-2.6.0-test11.orig/arch/ia64/lib/dec_and_lock.c
linux-2.6.0-test11/arch/ia64/lib/dec_and_lock.c
--- linux-2.6.0-test11.orig/arch/ia64/lib/dec_and_lock.c 1970-01-01
01:00:00.000000000 +0100
+++ linux-2.6.0-test11/arch/ia64/lib/dec_and_lock.c 2003-12-11
10:42:49.000000000 +0100
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2003 Jerome Marchand, Bull S.A.
+ *
+ * This file is released under the GPLv2, or at
+ * your option any later version.
+ *
+ * ia64 version of "atomic_dec_and_lock()" using
+ * the atomic "cmpxchg" instruction.
+ * This code is an adaptation of the x86 version
+ * of "atomic_dec_and_lock()".
+ */
+
+#include <linux/spinlock.h>
+#include <asm/atomic.h>
+
+int atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
+{
+ int counter;
+ int newcount;
+
+repeat:
+ counter = atomic_read(atomic);
+ newcount = counter-1;
+
+ if (!newcount)
+ goto slow_path;
+
+ if(cmpxchg(&atomic->counter, counter, newcount) != counter)
+ goto repeat;
+ return 0;
+
+slow_path:
+ spin_lock(lock);
+ if (atomic_dec_and_test(atomic))
+ return 1;
+ spin_unlock(lock);
+ return 0;
+}
[-- Attachment #2: lockmeter ia64 patch --]
[-- Type: TEXT/PLAIN, Size: 1914 bytes --]
diff -urN linux-2.6.0-test11.lockmeter.orig/arch/ia64/lib/dec_and_lock.c linux-2.6.0-test11.lockmeter/arch/ia64/lib/dec_and_lock.c
--- linux-2.6.0-test11.lockmeter.orig/arch/ia64/lib/dec_and_lock.c 2003-12-11 10:44:10.000000000 +0100
+++ linux-2.6.0-test11.lockmeter/arch/ia64/lib/dec_and_lock.c 2003-12-11 10:43:47.000000000 +0100
@@ -13,6 +13,7 @@
#include <linux/spinlock.h>
#include <asm/atomic.h>
+#ifndef ATOMIC_DEC_AND_LOCK
int atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
{
int counter;
@@ -36,3 +37,4 @@
spin_unlock(lock);
return 0;
}
+#endif
diff -urN linux-2.6.0-test11.lockmeter.orig/include/asm-ia64/spinlock.h linux-2.6.0-test11.lockmeter/include/asm-ia64/spinlock.h
--- linux-2.6.0-test11.lockmeter.orig/include/asm-ia64/spinlock.h 2003-12-11 10:09:42.000000000 +0100
+++ linux-2.6.0-test11.lockmeter/include/asm-ia64/spinlock.h 2003-12-11 10:15:45.000000000 +0100
@@ -247,13 +247,27 @@
extern void _metered_spin_unlock(spinlock_t *lock);
/*
- * Use a less efficient, and inline, atomic_dec_and_lock() if lockmetering
- * so we can see the callerPC of who is actually doing the spin_lock().
- * Otherwise, all we see is the generic rollup of all locks done by
- * atomic_dec_and_lock().
+ * Matches what is in arch/ia64/lib/dec_and_lock.c, except this one is
+ * "static inline" so that the spin_lock(), if actually invoked, is charged
+ * against the real caller, not against the catch-all atomic_dec_and_lock
*/
static inline int atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
{
+ int counter;
+ int newcount;
+
+repeat:
+ counter = atomic_read(atomic);
+ newcount = counter-1;
+
+ if (!newcount)
+ goto slow_path;
+
+ if(cmpxchg(&atomic->counter, counter, newcount) != counter)
+ goto repeat;
+ return 0;
+
+slow_path:
_metered_spin_lock(lock);
if (atomic_dec_and_test(atomic))
return 1;
^ permalink raw reply
* Re: Intel centrino drivers being withheld?
From: Pavel Machek @ 2003-12-10 19:38 UTC (permalink / raw)
To: bill davidsen; +Cc: linux-kernel
In-Reply-To: <bpu4bp_vp8_1@gatekeeper.tmr.com>
Hi!
> At the moment the Pentium-M seems to be about the longest life per pound
> going, which makes it desirable when life is more important than
> computing power. If a few hours is long enough there are lots of choices.
Really? I thought transmeta's run longer. And there were
some 386s running on 2 AA batteries. That should have best
"hours/kilograms" ratio. --p
^ permalink raw reply
* Re: mangle + TCP Flags
From: Jean-Marie @ 2003-12-11 9:55 UTC (permalink / raw)
To: netfilter
>If a module like this existed it would be a great way to violate the
>protocol and cause antisocial behaviour of your tcp stack.
Yes, I agree, but in any case there would be more efficient ways to
cause antisocial behaviour. In fact, in the beginning, my idea was to return a RST,ACK, for each SYN received on one of my closed ports, in order to make a scan tool belive that they are all open. (Perhaps it is useles but I found the idea amusing.
>Anyway such a module is not difficult to write. So it is possible, but
>nor the iptables package and the kernel, nor patch-o-matic
>do not contain such a module.
I saw yesterday that Craig Shelley did provide such a module on the devel-list in june but I can't recover the tarball he sended in attachment.
^ permalink raw reply
* ALSA mixing capability
From: Adam Tla/lka @ 2003-12-11 9:49 UTC (permalink / raw)
To: alsa-devel
Welcome
I'm using ALSA 1.0.0rc2 on snd_intel8x0 and .asoundrc:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pcm.mix {
type dmix
ipc_key 321456 # any unique value
ipc_key_add_uid true
slave {
pcm "hw:0,0"
periods 0
period_time 0
period_size 1024 # must be power of 2
buffer_size 4096 # ditto
}
bindings {
0 0
1 1
}
}
ctl.mix { type hw card 0 }
pcm.dsp0 { type plug slave.pcm "mix" }
ctl.mixer0 { type hw card 0 }
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
My problem:
when using wavplay with OSS ALSA emulation playing 22050 and 11025 Hz
.wav files works OK
but with AOSS lib using pcm.dsp0 defined above I can't play 11025 Hz
.wav file:
$ aoss wavplay lburn2.wav
Pathname: lburn2.wav
Device: /dev/dsp
Sampling Rate: 11025 Hz
Mode: Mono
Samples: 5999
Bits: 8
Unable to set audio sampling rate
but 22050 HZ .wav is played correctly.
So my question is how properly compose .asoundrc file so we could mix
all sound sources which use ALSA natively
through -Dmix virtual device and OSS apps routed through AOSS lib? Is
this possible? Is this explained somewhere?
Next case is a possibility to create a virtual mixer so ctl.mix
virtually sets level of particular source before mixing
it with others sources so playind applications could set volumen of only
his source. Is that possible?
I thing that solution should be a snd kernel module which does this jobs
(mixing and correcly setting volume level independently
for all apps, using hardware mixing if possible and software if not, DMA
mapping etc.) which lays below OSS pcm emulation
module and pcm0p device and above hardware so no configuration changes
in all apps are needed.
If it will working as a kernel high priority thread then some latency
problems will gone too.
Regards
--
Adam Tla/lka mailto:atlka@pg.gda.pl ^v^ ^v^ ^v^
Computer Center, Technical University of Gdansk, Poland
PGP public key: finger atlka@sunrise.pg.gda.pl
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply
* Re: Installing Linux on a E250 with serial console: cannot get the boot prompt
From: Stephane Bortzmeyer @ 2003-12-11 9:47 UTC (permalink / raw)
To: ultralinux
In-Reply-To: <marc-linux-ultrasparc-107094852316886@msgid-missing>
On Wed, Dec 10, 2003 at 09:38:28AM -0800,
Eric Brower <ebrower@usa.net> wrote
a message of 77 lines which said:
> You should be able to use the serial connector on the RSC card to
> boot to OBP.
It just displays "login:" and, of course, I do not have the login and
password. According to the RSC user's guide, you need Solaris to
install it, anyway. The machine is new so RSC should not be configured.
^ permalink raw reply
* Re: jffs2/nand flash
From: John Stirling @ 2003-12-11 9:42 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
In-Reply-To: <1071061636.25344.70.camel@dobblers.nexus.co.uk>
I've done some further investigation on this.
The problem I was seeing was caused by a call to jffs2_full_dnode (in
write.c, alloc_mode=ALLOC_GC). This leaves stuff in the write_buf, but
never gets round to actually writing it to flash unless another write
happens in the meantime.
When I copy a file the flushing procedure seems to work. I see an
initial page write, followed a couple of seconds later by another write
of the remaining stuff in the write_buf. However, following this, more
stuff remains in the write_buf, which again never gets written to flash
and produces errors again when the kernel is rebooted.
As an experiment i removed the checked for ino!=0 at the end of
jffs2_flash_writev
ie
replaced
if (c->wbuf_len && ino)
jffs2_wbuf_dirties_inode(c, ino);
with
if (c->wbuf_len)
jffs2_wbuf_dirties_inode(c, ino);
Having done this, almost all the reported errors disappeared next time I
rebooted.
Also, I noticed that having copied a few files manually then some of the
errors disappeared.
So, is it possible that the errors that are being reported are not
really errors and will get cleaned up via garbage collection at some
point. If so, then it would be nice if they weren't reported are
errors..
On Wed, 2003-12-10 at 13:07, John Stirling wrote:
> > Not fsync() but a flush should happen then, yes.
> >
> > Compile with CONFIG_JFFS2_FS_DEBUG=1. Run 'sync' after writing your
> > file. Show me the output.
> >
>
> See extract from kernel log below. Setting FS_DEBUG=1 didn't seem to
> produce any more debug info. sync didn't cause a further page write..
>
>
>
^ permalink raw reply
* Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
From: Duncan Sands @ 2003-12-11 9:45 UTC (permalink / raw)
To: Oliver Neukum, Alan Stern
Cc: David Brownell, Vince, Randy.Dunlap, mfedyk, zwane, linux-kernel,
USB development list
In-Reply-To: <200312101758.02334.oliver@neukum.org>
> > > > __usb_set_configuration - lockless version
> > > > usb_set_configuration - locked version
> > >
> > > Partially done.
> > > That's what the _physical version of usb_reset_device() is about.
> >
> > Unfortunately, usb_physical_reset_device calls usb_set_configuration
> > which takes dev->serialize.
>
> That is bad, but the solution is obvious.
> All such operations need a _physical version.
> At first sight this may look less elegant than some lock dropping schemes,
> but it is a solution that produces obviously correct code paths with
> respect to locking.
Hi Oliver, I agree, except that there are several layers of locking: dev->serialize
but also the bus rwsem. So does "physical" mean no subsys.rwsem or no
dev->serialize or both?
Ciao, Duncan.
int usb_reset_device(struct usb_device *udev)
{
struct device *gdev = &udev->dev;
int r;
down_read(&gdev->bus->subsys.rwsem);
r = usb_physical_reset_device(udev);
up_read(&gdev->bus->subsys.rwsem);
return r;
}
^ 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.