* Re: problem with UN-DNAT, source is same machine
From: Joel Newkirk @ 2002-12-16 21:22 UTC (permalink / raw)
To: Frank Wallingford, netfilter
In-Reply-To: <3DF2E9D3.6010006@technologist.com>
On Sunday 08 December 2002 01:42 am, Frank Wallingford wrote:
> Here's one I can't quite wrap my head around.
> iptables -t nat -A OUTPUT -d 192.168.0.100 --dport 22 \
> -j DNAT --to 192.168.0.200
>
> Now, I'm only trying to get this one case working:
>
> (from machine 192.168.0.100:) ssh 192.168.0.100
>
> and I'd like it to connect to 192.168.0.200. I'm not sure why it
> isn't.
> From what I understand, this should be the case:
> (1) The packet starts as
> SOURCE: 192.168.0.100:port_a (some random port)
> DEST: 192.168.0.100:22
> (2) While traversing the OUTPUT chain in the NAT table, it's changed:
> SOURCE: 192.168.0.100:port_a
> DEST: 192.168.0.200:22
> (3) The packet is sent out
> (4) Host 192.168.0.200 sees it and sends the reply
> SOURCE: 192.168.0.200:22
> DEST: 192.168.0.100:port_a
> (5) The packet arrives, and is un-snat'd:
> SOURCE: 192.168.0.100:22
> DEST: 192.168.0.100:port_a
> (6) The local process sees a reply from the local machine, and accepts
> it.
>
> What's actually happening is that it's getting as far as (4), and the
> reply comes in, but the local process doesn't accept it. I'm guessing
> this is because it wasn't un-snat'd correctly, or I'm doing something
> wrong.
Are you sure you are allowing it through the INPUT chain? You can
confirm whether or not it is reaching that point with two log rules, one
as first in PREROUTING, one as first in INPUT. If it hits both, then it
is likely being dropped in INPUT, but is getting unDNATted properly. If
it gets here, check the info on the packet logged at the INPUT chain and
make sure that you have a rule to allow it through.
j
^ permalink raw reply
* Re: ext3 updates for 2.4.20
From: Chris Mason @ 2002-12-16 21:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: lkml, ext3-users@redhat.com
In-Reply-To: <3DFCE5E7.A8BE82B4@digeo.com>
Hmmm, this took me a while to find the first time around in the
commit_super code, and I almost forgot about it.
Looking at the loop in sync_supers()
while (sb != sb_entry(&super_blocks))
if (sb->s_dirt) {
sb->s_count++;
spin_unlock(&sb_lock);
Right here, we can race against kill_super, which means an unmount can
make the FS go away completely. The only thing that saves the
write_super() call is a check for s->s_root != NULL. Since we don't
check that before calling sync_fs, it should race against an unmount.
down_read(&sb->s_umount);
write_super(sb);
if (wait && sb->s_op && sb->s_op->sync_fs)
sb->s_op->sync_fs(sb);
drop_super(sb);
goto restart;
} else
Any reason ext3 can't have a check for s_root in there?
-chris
^ permalink raw reply
* Re: possible problems with rc6 aplay
From: Mark Knecht @ 2002-12-16 21:20 UTC (permalink / raw)
To: Paul Davis; +Cc: martin-langer, Alsa-Devel, swpatrick
In-Reply-To: <20021216134609.VYJW9197.sccrgwc02.attbi.com@newmx2.fast.net>
This sounds like a fine solution Paul. I'll give it a shot.
Thanks!
On Mon, 2002-12-16 at 05:49, Paul Davis wrote:
> >Martin,
> > That might certainly be an answer. How would this amixer switch get
> >st in the first place? I wouldn't mind doing it by hand once as long as
> >it was then loaded after that.
>
> what you want is a short startup script (typically in somewhere under
> /etc/rc.d, but unfortunately this varies somewhat from linux
> distribution to linux distribution). it would look like this:
>
> #!/bin/sh
>
> HAMMERFALL=0 # change to match the card number of the
> # Hammerfall, as shown in /proc/asound/cards
> CLOCK_MODE=0 # auto-sync, the default condition.
> CLOCK_MODE_NAME="autosync"
>
> case $1 in
> start) if [ -f /some/path/to/this-host-is-master ] ; then
> CLOCK_MODE=1
> CLOCK_MODE_NAME="master"
> else
> CLOCK_MODE=2
> CLOCK_MODE_NAME="word clock"
> fi
> echo "Setting Hammerfall to $CLOCK_MODE_NAME mode ..."
> amixer -c $HAMMERFALL cset \
> iface=PCM,name='Sync Mode',numid=7 $CLOCK_MODE
> esac
> exit 0
>
> then, just create the file /some/path/to/this-host-is-master on one
> machine, and it will automatically set the Master switch when it boots
> up. the other machine will remain in AutoSync mode - if they are
> connected via word clock, you probably want to change that as well,
> using the same script.
>
> if you need more help with this, let me know. this is one of those
> areas where linux and its command line orientation proves so powerful
> (though to be fair, its probably possible to do something vaguely
> similar on windows, but not using such general-purpose tools).
>
> --p
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: How to do -nostdinc?
From: Keith Owens @ 2002-12-16 21:26 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-kernel
In-Reply-To: <20021216182919.GA1607@mars.ravnborg.org>
On Mon, 16 Dec 2002 19:29:19 +0100,
Sam Ravnborg <sam@ravnborg.org> wrote:
>On Sun, Dec 15, 2002 at 11:06:41PM +1100, Keith Owens wrote:
>> There are two ways of setting the -nostdinc flag in the kernel Makefile :-
>>
>> (1) -nostdinc $(shell $(CC) -print-search-dirs | sed -ne 's/install: \(.*\)/-I \1include/gp')
>> (2) -nostdinc -iwithprefix include
>>
>> The first format breaks with non-English locales, however the fix is trivial.
>>
>> (1a) -nostdinc $(shell LANG=C $(CC) -print-search-dirs | sed -ne 's/install: \(.*\)/-I \1include/gp')
>>
>Hi Keith.
>
>Based on the comments received, solution (2) seems to be OK.
>Do you agree?
Does gcc still mark -iwithprefix as deprecated? If it does then do not
rely on it and use (1a). If gcc will support -iwithprefix then use (2).
^ permalink raw reply
* Re: alsasound init script (Re: possible problems with rc6 aplay )
From: Mark Knecht @ 2002-12-16 21:18 UTC (permalink / raw)
To: Paul Davis; +Cc: Takashi Iwai, martin-langer, Alsa-Devel, swpatrick
In-Reply-To: <20021216152035.CZFC3512.sccrgwc01.attbi.com@newmx1.fast.net>
On Mon, 2002-12-16 at 07:23, Paul Davis wrote:
> >> that reminds me. the last version of the alsasound script that i saw
> >> did something very dangerous. it seemed to try to install *every*
> >> snd-card module it could find. if you have a system with an ISA bus,
> >> this can prove fatal to the system - many ISA device probes will kill
> >> the machine if the device is not present.
> >
> >well, you can find that the alsasound script tries to load the modules
> >aliased as "snd-card-[0-9]", not the all snd-card-* modules.
> >remember that there is no module named as such. that means, if such a
> >module is found, it was certainly configured by some means.
>
> ah. sorry, i missed the -c on modprobe. i take it all back :(
>
> --p
I wonder if this could have anything to do with a different problem I'm
seeing. I have a HDSP 9652 and a MidiMan 2X2 interface. The HDSP is
installed by alsaconf. The 2X2 is installed usign Fernando's
instructions from the Planet.
When I do a cold boot, the HDSP is always recognized first, and then the
MidiMan comes up as card 2, at least by reading the numbers of the
devices in /dev/snd. However, if I reboot, many times the system makes
the 2X2 card 1 and the HDSP card 2, and that breaks a lot of this
software.
What would cause this to happen and how could I stop it?
I have found that everything seems to work fine if I remember to unplug
the 2X2 when the reboot begins, but sometimes I don't remember and have
to go through one more boot cycle.
Cheers,
Mark
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: [Linux-ia64] ia64 SN update
From: Sam Ravnborg @ 2002-12-16 21:16 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805522@msgid-missing>
On man, dec 09, 2002 at 01:03:56 -0800, Jesse Barnes wrote:
> David, here's a patch to update SN support in the ia64 tree.
=== arch/ia64/sn/kernel/Makefile 1.7 vs edited ==--- 1.7/arch/ia64/sn/kernel/Makefile Sun Sep 22 16:34:28 2002
+++ edited/arch/ia64/sn/kernel/Makefile Tue Dec 3 18:07:29 2002
XXX
+.S.s:
+ $(CPP) $(AFLAGS) $(AFLAGS_KERNEL) -o $*.s $<
+.S.o:
+ $(CC) $(AFLAGS) $(AFLAGS_KERNEL) -c -o $*.o $<
Do you really need this. kbuild contains the above rules, and if it
does not work deleting the above lines I would like to know.
Same comment for sn1 and sn2.
Also could you please delete inclusion of Rules.make, it has disappeared
from Linus's tree.
Sam
^ permalink raw reply
* Re: pls help a beginner linux admin - problem with packetfilter setup
From: Joel Newkirk @ 2002-12-16 21:13 UTC (permalink / raw)
To: eugenio, netfilter
In-Reply-To: <NHEFIMOGNFCHOOHNLFFEMEHOCFAA.eugenius@freemail.hu>
On Saturday 07 December 2002 09:38 am, eugenio wrote:
> I need to set packetfiltering on a debian linux firewall to enable a
> network game.
> Necessary firewall settings are descibed here:
> http://support.microsoft.com/default.aspx?scid=KB;en-us;q240429
>
> The system has client computers with 192.168.1.1x fix local IP
> addresses (no DHCP), and a gateway with both internal (192.168.1.1)
> and external (both fixed) IP adresses, w/ two network card of course
> (eth0 - external, eth1 - internal).
>
> Can anyone give me a hint what settings are necessary?
I assume that the network is functional as it stands, and that the client
machines are SNATted to allow internet access already.
If your client computers are only functioning as clients in the game,
this should work:
iptables -A FORWARD -i eth1 -p tcp \
-m multiport --dport 6073,47624 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED \
-j ACCEPT
If you are allowing it only for specific machines, since you have static
local IPs, you can tighten this up as follows:
iptables -A FORWARD -s a.b.c.d -p tcp \
-m multiport --dport 6073,47624 -j ACCEPT
iptables -A FORWARD -s a.b.c.d -m state \
--state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -d a.b.c.d -m state \
--state ESTABLISHED,RELATED -j ACCEPT
This will allow the clients to communicate to the gameserver/host
initially, then allow established and related connections each way.
Just use this trio of rules for each IP that you want to allow. Note
that this will allow est/rel for ALL allowed connections, (but only from
the specified machines in the second version) so if this is undesireable
then you will need to specify each port range explicitly, like:
iptables -A FORWARD -i eth1 -p tcp -m multiport
--dport 6073,47624 -j ACCEPT
iptables -A FORWARD -p tcp --dport 2300:2400 -j ACCEPT
iptables -A FORWARD -p udp --dport 2300:2400 -j ACCEPT
You can tighten up any of these rules by specifying IP's of allowed local
machines, and in some cases you can specify IP's of remote machines,
since some of these games only ever connect to one or a small number of
IP's that handle all gaming communications. However, the state rules
will need to be duplicated for input AND output traffic in this case,
since both are required for the port 2300-2400 (or EST/REL) connections.
Note also that while EST/REL may seem insecure, it is in fact quite a bit
more secure than simply opening up 204 ports permanently. If at all
possible, the second approach, or the initial connections as specified
there with the single EST/REL from the first, is the best answer. If
you get things running this way first, you can log some game traffic and
see if there is a consistent remote IP used, and rewrite rules with that
if desired, which will be about as tight as you can get it, without
manually enabling/disabling all of this on demand when gaming is
desired.
Also, depending upon how the particular game communicates, you may find
it necessary to explicitly open the ports as in the third example, since
some games allow or even rely on communication directly between client
machines, and this would represent a new connection, not related
(state-wise) to the gameserver connection.
Finally if a local machine will function as a host (if even possible,
depends on the game) then you need to allow the reverse of the initial
connection as well, but will also need DNAT to allow internet clients to
connect, and only one server will probably be possible.
j
^ permalink raw reply
* Re: counting shell args
From: Mike Dresser @ 2002-12-16 21:12 UTC (permalink / raw)
To: Scott Taylor; +Cc: linux-admin
In-Reply-To: <5.1.1.6.0.20021216125932.01c63ca8@mustang>
On Mon, 16 Dec 2002, Scott Taylor wrote:
> Yeah, very. I remember once about 10 years ago someone told me that if I
> study UNIX and can't find something, it's because the attitude is: "you
> don't need to know that!" Now I know what he meant. Good thing it's no
> longer like that. LMAO.
The worst part about writing this backup script of mine was finding the
return status from the previous pipe in the script.
smbtar -s $pcname -x $share -p $password -u $username -t - -X /win95 /win98 | gzip -1 > $filename.tar.gz
if [ $PIPESTATUS -eq 0 ] && [ `ls -s $filename.tar.gz | awk '{print $1}'` -gt 25 ]; then
$PIPESTATUS was hard to find.
All that because smbtar doesn't properly report errors, you have to
check that it did in fact report a zero error return, AND verify it
didn't just dump a 0 byte file cause the machine was unreachable. Even
so, if the Windows PC crashes in the middle of the backup(happens enough
to be annoying!), it'll still think the backup ran just fine, and dump a 0
status back at you, making the backup incomplete.
Most odd. :D
Mike
^ permalink raw reply
* Re: increase base memory
From: Stas Sergeev @ 2002-12-16 21:07 UTC (permalink / raw)
To: linux-msdos
Hello.
Bart Oldeman wrote:
> if you run dosemu in "dumb" mode, well, f000 is even possible, ie.,
> 960k, if you disable EMS too.
Just one question: are we all using
a vidram/memmax here in the real dos?
Or do we already have a dosemu-specific
programs out there?:)
Of course having 960k is cool, and
knowing that dosemu can do something
more than you can do in a real dos is
also great, but what's the practical
use? Oh yes, it will allow you to not
"lh" your TSR's in autoexec, so if the
person knows what he/she do (ie will
not try VGA graphics and write the
useless bugreports later) then why not,
but still I don't see any real reasons.
So if the program requires 960K, then
it might just use XMS/EMS.
As for the original cobol problem, it
turned to be this:
---
Yes, The cobol is Microfocus and using
XM for dosextender in real DOS.
---
and also this:
---
The application
has one option to show the tiff image.
---
So in that case occupying the video
mem is definitely not an option.
And in general I really still see no
practical reasons for that.
Note that under dosemu you actually need
even less resident progs in your memory
than you need under a pure dos, as
dosemu does provide the basic drivers
(ems, xms etc) itself.
But well, if people just think it is
cool that we can do that, then I agree,
it is nice:) Esp in a terminal/dumb modes
where it is also safe due to no graphics...
^ permalink raw reply
* Re: counting shell args
From: Scott Taylor @ 2002-12-16 21:05 UTC (permalink / raw)
To: linux-admin
In-Reply-To: <Pine.LNX.4.33.0212161555240.25857-100000@router.windsormac hine.com>
At 12:57 PM 12/16/02, Mike Dresser wrote:
>On Mon, 16 Dec 2002, Scott Taylor wrote:
>
> > >if [ $# -lt 2 ]; then
> >
> > Man! That's been driving me nuts for like an hour now! Thanks. It's
> > still driving me nuts why I couldn't find it in man bash or man test
> though.
>
># Expands to the number of positional parameters in
> decimal.
I saw that, and chose to ignore it, last time that happens. lol
>Doesn't exactly jump out and say, "HEY, I COUNT PARAMETERS"
No kidding. Heh, it's what happens when you run such a tight ship you
rarely need to do anything but play doom/quake to run those network tests. =P
>I looked for many hours for that one myself when making a backup script.
>Very annoying :)
Yeah, very. I remember once about 10 years ago someone told me that if I
study UNIX and can't find something, it's because the attitude is: "you
don't need to know that!" Now I know what he meant. Good thing it's no
longer like that. LMAO.
Cheers Mike.
^ permalink raw reply
* FYI
From: Richard B. Johnson @ 2002-12-16 21:15 UTC (permalink / raw)
To: Linux kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 193 bytes --]
Small Linux Christmas Poem.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 888 bytes --]
^ permalink raw reply
* [Linux-ia64] Re: Use of __ia64_syscall() - syscall interface
From: David Mosberger @ 2002-12-16 21:04 UTC (permalink / raw)
To: linux-ia64
>>>>> On Mon, 16 Dec 2002 17:07:18 +0100 (NFT), Joel GUILLET <Joel.Guillet@bull.net> said:
Joel> This doesn't compile on a Itanium. I got a "undefined
Joel> reference to __ia64_syscall()"
Please use the syscall() routine instead. The stuff in unistd.h is
for kernel-use only.
--david
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Jonah Sherman @ 2002-12-16 16:07 UTC (permalink / raw)
To: Mark Mielke; +Cc: linux-kernel
In-Reply-To: <20021216175432.GA5094@mark.mielke.cc>
On Mon, Dec 16, 2002 at 12:54:32PM -0500, Mark Mielke wrote:
> Programs that self verify their own CRC may get a little confused (are
> there any of these left?), but other than that, 'goto is better avoided'
> as well, but sometimes 'goto' is the best answer.
This shouldn't cause any problems. The only way this would cause a problem is if the program had direct system calls in it, but as long as they are using libc(what self-crcing program doesn't use libc?), the changes would only be made to code pages inside libc, so the program's own code pages would remain untouched.
^ permalink raw reply
* Re: counting shell args
From: Mike Dresser @ 2002-12-16 20:57 UTC (permalink / raw)
To: Scott Taylor; +Cc: linux-admin
In-Reply-To: <5.1.1.6.0.20021216124934.01c406e8@mustang>
On Mon, 16 Dec 2002, Scott Taylor wrote:
> >if [ $# -lt 2 ]; then
>
> Man! That's been driving me nuts for like an hour now! Thanks. It's
> still driving me nuts why I couldn't find it in man bash or man test though.
# Expands to the number of positional parameters in
decimal.
Doesn't exactly jump out and say, "HEY, I COUNT PARAMETERS"
I looked for many hours for that one myself when making a backup script.
Very annoying :)
Mike
^ permalink raw reply
* Re: Re: [Alsa-user] fm801 driver status?
From: Friedrich Ewaldt @ 2002-12-16 20:55 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Thierry Vignaud, alsa-user, alsa-devel
In-Reply-To: <s5hznr6roae.wl@alsa2.suse.de>
Hi!
Hopefully, the following information is of some help.
Takashi Iwai wrote:
>to be sure, could you elaborate the symptom again and the detail of
>your system (kernel version, applied patches, ALSA version)?
>
>
kernel: 2.4.19-16mdkcustom, compiled with sound and without alsa. I
compiled from the kernel source delivered with mandrake 9.0 and did not
apply any patches.
alsa: cvs snapshot 2002-12-09.tar.bz2 with your patch (that fixes the
i/o port error in /var/log/messages) applied
system:
duron 850, 128 MB PC 133
NMC (the name changed to enmic, I think) board, KT-133 chipset with via686a.
Award bios 01/10/2001-8363-686A-6A6LMNM9C-00
>especially, please check the following:
>
>- loading the module and unloading it immediately works?
>
yep. /proc/asound builds up immediately, lsmod shows snd, ... modules
immediately after modprobing
>- the port and irq number are correct, i.e. match with the resources
> listed on lspci?
>
info from /proc/asound/cards:
FM801-AS at 0xec00, irq 10
lspci output:
00:0b.0 Multimedia audio controller: Fortemedia, Inc Xwave QS3000A
[FM801] (rev a0)
Subsystem: Fortemedia, Inc: Unknown device 1319
Flags: bus master, medium devsel, latency 40, IRQ 10
I/O ports at ec00 [size=128]
(IRQ 10, I/O ec00 also shown by window?)
>- playback (via aplay) works? does the system hang up at the start,
> during the playback or at the stop?
>
playback works. I even hear the correct sound when I plug in headphones :-)
The system locks when stopping playback. (If only I had infinite audio
files...)
>- during the playback, does the count in /proc/interrupts increases?
> (check with another terminal)
>
>
the count at '10' (I assume this is irq 10) increases during playback by
approx. 10-15 per second.
>a typical reason of such a hang up is either the wrong spinlocks,
>unexpected infinite loops in the driver code, or the interrupt
>storms. if it's the interrupt storm, then it can be related with the
>hardware, often motherboard chipset, or BIOS version.
>or, could it be because of ACPI? did you apply it?
>
>
I unselected ACPI before compiling the kernel. ACPI is switched off in
the bios. (I have only APM running as power management)
>ciao,
>
>Takashi
>
>
Is there anything else I could do?
cheers,
fe
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: counting shell args
From: Scott Taylor @ 2002-12-16 20:53 UTC (permalink / raw)
To: linux-admin
In-Reply-To: <Pine.LNX.4.33.0212161545230.25857-100000@router.windsormac hine.com>
At 12:47 PM 12/16/02, Mike Dresser wrote:
>On Mon, 16 Dec 2002, Scott Taylor wrote:
>
> > I'm sure I've seen, probably even use it before, but I can't remember or
> > find it now; does anyone remember how to count the number of arguments sent
> > to a bash script?
>
>$#
>
>for example:
>
>if [ $# -lt 2 ]; then
Man! That's been driving me nuts for like an hour now! Thanks. It's
still driving me nuts why I couldn't find it in man bash or man test though.
^ permalink raw reply
* i810 sound starts and stops for 2.4.XX and i845PE chipset
From: edward.kuns @ 2002-12-16 21:03 UTC (permalink / raw)
To: linux-kernel; +Cc: edward.kuns
Please CC me at edward.kuns at rockwellfirstpoint.com in your responses.
I have a Gigabyte GA-8PE667 Ultra motherboard (aka P4 Titan 667 Ultra) with
the i845PE chipset. According to the motherboard manual, it uses the
Realtek ALC650 CODEC.
With Red Hat 8.0's default kernel (2.4.18-14) and with the most recent
update kernel (2.4.18-18.8.0) -- both the i686 version -- sound works but
will stop and start at random, long intervals. This occurs no matter what
the source of the sound. (xine, chromium, whatever) Of course, those two
kernel versions use the same i810 source file (version 0.22).
I've tried to boot 2.4.20-ac2 but it doesn't even boot (due to the Promise
controller and other issues I'll bring up in a separate EMail) so I naively
copied the i810_audio.c file from that kernel tree to the Red Hat
2.4.18-18.8.0 tree and recompiled. There is no difference in behavior. I
threw a SoundBlaster Live! card in there and with that card, sound output
works perfectly. (I first disabled the i810 sound in the BIOS ... I
haven't tried the two together.)
Below are the dmesg output for 2.4.18-14 default (first) and for
2.4.18-18.8.0 with i810_audio.c from 2.4.20-ac2:
Red Hat 8.0 kernel 2.4.18-14
Dec 14 22:51:31 kilroy kernel: Intel 810 + AC97 Audio, version 0.22,
13:45:06 Sep 4 2002
Dec 14 22:51:31 kilroy kernel: PCI: Found IRQ 11 for device 00:1f.5
Dec 14 22:51:31 kilroy kernel: PCI: Sharing IRQ 11 with 00:1f.3
Dec 14 22:51:31 kilroy kernel: PCI: Setting latency timer of device 00:1f.5
to 64
Dec 14 22:51:31 kilroy kernel: i810: Intel ICH4 found at IO 0xd800 and
0xd400, IRQ 11
Dec 14 22:51:31 kilroy kernel: i810_audio: Audio Controller supports 6
channels.
Dec 14 22:51:31 kilroy kernel: i810_audio: Defaulting to base 2 channel
mode.
Dec 14 22:51:31 kilroy kernel: ac97_codec: AC97 Audio codec, id:
0x414c:0x4720 (ALC650)
Dec 14 22:51:31 kilroy kernel: i810_audio: AC'97 codec 0, new EID value =
0x05c7
Dec 14 22:51:31 kilroy kernel: i810_audio: AC'97 codec 0, DAC map
configured, total channels = 6
Dec 14 22:51:31 kilroy modprobe: modprobe: Can't locate module
sound-service-0-3
Red Hat 8.0 kernel 2.4.18-18.8.0 but with i810_audio.c from 2.4.20-ac2
Dec 14 23:43:06 kilroy kernel: Intel 810 + AC97 Audio, version 0.24,
23:22:57 Dec 14 2002
Dec 14 23:43:06 kilroy kernel: PCI: Found IRQ 11 for device 00:1f.5
Dec 14 23:43:06 kilroy kernel: PCI: Sharing IRQ 11 with 00:1f.3
Dec 14 23:43:06 kilroy kernel: PCI: Setting latency timer of device 00:1f.5
to 64
Dec 14 23:43:06 kilroy kernel: i810: Intel ICH4 found at IO 0xd800 and
0xd400, MEM 0xec002000 and 0xec003000, IRQ 11
Dec 14 23:43:06 kilroy kernel: i810: Intel ICH4 mmio at 0xe1c85000 and
0xe1c87000
Dec 14 23:43:07 kilroy kernel: i810_audio: Primary codec has ID 0
Dec 14 23:43:07 kilroy kernel: i810_audio: Audio Controller supports 6
channels.
Dec 14 23:43:07 kilroy kernel: i810_audio: Defaulting to base 2 channel
mode.
Dec 14 23:43:07 kilroy kernel: i810_audio: Resetting connection 0
Dec 14 23:43:07 kilroy kernel: i810_audio: Connection 0 with codec id 0
Dec 14 23:43:07 kilroy kernel: ac97_codec: AC97 Audio codec, id:
0x414c:0x4720 (ALC650)
Dec 14 23:43:07 kilroy kernel: i810_audio: AC'97 codec 0, new EID value =
0x05c7
Dec 14 23:43:07 kilroy kernel: i810_audio: AC'97 codec 0, DAC map
configured, total channels = 6
Output of "lspci" with no options (from after I threw the SoundBlaster
Live! on):
00:00.0 Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host
Bridge (rev 02)
00:01.0 PCI bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset AGP Bridge
(rev 02)
00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 02)
00:1d.7 USB Controller: Intel Corp. 82801DB USB EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 82)
00:1f.0 ISA bridge: Intel Corp. 82801DB ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801DB ICH4 IDE (rev 02)
00:1f.3 SMBus: Intel Corp. 82801DB SMBus (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801DB AC'97 Audio (rev
02)
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX440]
(rev a3)
02:00.0 SCSI storage controller: Adaptec AIC-7892B U160/m (rev 02)
02:02.0 Serial controller: US Robotics/3Com 56K FaxModem Model 5610 (rev
01)
02:03.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev
04)
02:03.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev
01)
02:07.0 USB Controller: NEC Corporation USB (rev 41)
02:07.1 USB Controller: NEC Corporation USB (rev 41)
02:07.2 USB Controller: NEC Corporation USB 2.0 (rev 02)
02:08.0 Ethernet controller: Intel Corp. 82801BD PRO/100 VE (CNR) Ethernet
Controller (rev 82)
02:0c.0 RAID bus controller: Promise Technology, Inc. PDC20276 IDE (rev 01)
Output of "lspci -vv" pasting in only the piece from the Intel audio
controller:
00:1f.5 Multimedia audio controller: Intel Corp. 82801DB AC'97 Audio (rev
02)
Subsystem: Giga-byte Technology: Unknown device a002
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
Interrupt: pin B routed to IRQ 11
Region 0: I/O ports at d400 [size=256]
Region 1: I/O ports at d800 [size=64]
Region 2: Memory at ec002000 (32-bit, non-prefetchable) [size=512]
Region 3: Memory at ec003000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
I see the dmesg messages shown above whenever something starts using sound,
but when the sound stops and later restarts, there are no messages to dmesg
nor to /var/log/message. The sound just quits, and some time later (two
minutes, five minutes, ten minutes.....) comes back. Again, this happens
regardless of the sound source.
I do not have these problems on another board with the i845G chipset, so I
am assuming the i845PE has changed something. (?) Or perhaps something
else is different between an Intel board with i845G and a Gigabyte board
with i845PE.
I haven't yet tried any of the 2.5.XX series, nor have I tried other
versions of 2.4.xx beyond what i mentioned above.
Any suggestions? Ideas? Patches? (grin) Let me know if there is
anything I can do to help research this. I'm not afraid of patches or
mucking around in kernel code -- part of my living involves working with
kernel code and drivers on a simpler and older OS -- but I'm not at all
familiar with PCI or the details of modern chipset programming.
Thanks
Eddie
P.S. We are required to use Notes here. I hope that this message will not
be sent HTML formatted.....
--
Edward Kuns
Technical Staff Member
Rockwell FirstPoint Contact
edward.kuns@rockwellfirstpoint.com
www.rockwellfirstpoint.com
^ permalink raw reply
* Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?
From: Russ Dill @ 2002-12-16 21:21 UTC (permalink / raw)
To: manningc2; +Cc: David Woodhouse, Wolfgang Denk, Paul Nash, Linux-MTD (E-mail)
In-Reply-To: <20021216210640.C31D314C2B@dragon.actrix.co.nz>
On Mon, 2002-12-16 at 14:02, Charles Manning wrote:
> Intel's flash is expensive. Figure somwhere over $1 per MB. NAND costs
> approx 30c/MB + SDRAM approx 20c/MB. Intel's flash thus costs approx twice
> what a NAND/RAM image does.
>
> One NAND flash footprint can give you up to 256MB of storage.
>
> NOR fully sucks for any sort of writeable file system performance. NAND runs
> a very usable fs with YAFFS or JFFS2.
>
> The only benefit I can see in NOR is a faster boot. This is becoming less of
> an issue as more designs switch to sleep/resume models.
It really depends on how much data you store, and how you use that data.
Sure, for you, with a dynamic file system, and 256M of storage, NAND is an
easy choice. But many designs out there have static file systems, use 2M or
4M of flash, and for such designs, NOR offers a lot more simplicity for around
the same cost as a NAND + boot logic. With NOR flash, I can put a couple
cramfs filesystems on there, and use the boot block for storing a simple
journalled config, reliably. I don't have to worry about setting aside blocks
in case one goes bad.
I think this is the market intel is targeting, just change 2M or 4M to 4M or 8M
(no more compressed fs).
^ permalink raw reply
* Re: Linux v2.5.52
From: Linus Torvalds @ 2002-12-16 20:54 UTC (permalink / raw)
To: Larry McVoy; +Cc: Ben Collins, Christoph Hellwig, Kernel Mailing List
In-Reply-To: <20021216123932.B6887@work.bitmover.com>
On Mon, 16 Dec 2002, Larry McVoy wrote:
>
> > Alternatively, never EVER make a patch against the "current kernel
> > version". Only make a patch against the _last_ kernel that you merged
> > with, and if I cannot apply it I will tell you so. Making a patch just
> > between your tree and mine will _always_ end up losing fixes.
>
> I think this is a good approach. If people sent Linus patches with some
> indication of the baseline of the patch, such as BASELINE=v2.5.49 in the
> header of the patch,
The problem here is that I often cannot do a sane merge.
I have no problem at all merging stuff that is a week old or so (major
clashes happen sometimes, and I ask for help, but it's rare). However, if
somebody really uses a major external CVS tree and does big patches,
eventually the likelihood of a problem grows big enough that the patch
sender might as well merge _first_ anyway, since otherwise I'll just ask
for his help.
HOWEVER, even if I end up having to ask for help, this is probably
preferable to the "just install my tree" approach, since at least we don't
lose bugfixes and other updates silently.
Linus
^ permalink raw reply
* Re: counting shell args
From: Mike Dresser @ 2002-12-16 20:47 UTC (permalink / raw)
To: Scott Taylor; +Cc: linux-admin
In-Reply-To: <5.1.1.6.0.20021216123048.01c06918@mustang>
On Mon, 16 Dec 2002, Scott Taylor wrote:
> I'm sure I've seen, probably even use it before, but I can't remember or
> find it now; does anyone remember how to count the number of arguments sent
> to a bash script?
$#
for example:
if [ $# -lt 2 ]; then
^ permalink raw reply
* Re: Domain transition
From: Tom @ 2002-12-16 20:46 UTC (permalink / raw)
To: Richard Mayo; +Cc: SELinux
In-Reply-To: <OF0E5EECFE.7EB8F6E6-ON85256C91.006E1E8E@caci.com>
On Mon, Dec 16, 2002 at 03:09:59PM -0500, Richard Mayo wrote:
> 1) What is "domain transition"? I've configured my system such that it
> doesn't happen, but I'm wondering if it's the best way to go.
It's not. Domain transitions are necessary. It's something like the
SELinux equivalent of setuid. For example, when init starts apache, you
definitely do want the initrc domain to change into the apache domain.
> 2) Is there a text file on my system with the list of user roles or is
> that information stored some other way?
look into /etc/security. it has changed around a little recently, but
there should be something like default_* in there with the information
you are looking for.
> 3) Can I configure the operating system NOT to ask for a user role on
> login? I would much prefer to have user role determined BY the login.
I'm sure it's possibly to skip the check, e.g. if the user is only
allowed to be in a single domain anyway. But I believe you would need
to patch the login code for this.
--
http://web.lemuria.org/pubkey.html
pub 1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
Key fingerprint = C731 64D1 4BCF 4C20 48A4 29B2 BF01 9FA1 2D7A 04F5
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: Problems with CONFIG_PREEMPT
From: Jun Sun @ 2002-12-16 20:45 UTC (permalink / raw)
To: Colin.Helliwell; +Cc: linux-mips, jsun
In-Reply-To: <OF9DA9DC55.9D9F4E46-ON80256C91.002C0064@zarlink.com>
Several possibilities:
1) Not all MIPS boards can run pre-k. At minimum, you need to use
NEW_TIME_C, Or else you have to take a lot of stuff youself.
2) Not sure if all MIPS patches are in RML's patch. If you pass the URL
pointer, I can take a look.
3) Even with all above taken care of, there are still unsolved issues
(such as math emul not pre-k safe, some cache operations, etc).
However, these problems usually are much harder to show up. You won't
see them unless you delibrately want to. :-)
Jun
On Mon, Dec 16, 2002 at 01:58:11PM +0000, Colin.Helliwell@Zarlink.Com wrote:
> I've been porting the MIPS kernel to our system-on-chip hardware
> (4KEc-based) and have encountered a problem with a pre-emptible patch. The
> original kernel was the 2.4.19 from the CVS server, onto which I applied
> Robert Love's preemptible patch (preempt-kernel-rml-2.4.19-2.patch), plus
> the addition of a #include to softirq.h, and a missing definition for
> release_irqlock() in hardirq.h.
> I've found that when CONFIG_PREEMPT is set, it no longer loads the
> (non-compressed) initrd correctly - about 1.8MB through loading (2MB total)
> I get a Data Bus Error. A typical call trace shown by the oops is shown
> below, and looks a little 'confused' to me, so I'm thinking there may be
> some stack corruption going on?
>
> Address Function
>
> 801174fc tasklet_hi_action
> 801af0a4 printChipInfo
> 801af0a4 printChipInfo
> 8013bf50 sys_write
> 801089c4 stack_done
> 80108b28 reschedule
> 801133d0 _call_console_drivers
> 80113ad8 release_console_sem
> 80113848 printk
> 801506b8 sys_ioctl
> 801af0f8 printChipInfo
> 8014ccd4 sys_mkdir
> 801af0a4 printChipInfo
> 80100470 init
> 80100470 init
> 80100840 prepare_namespace
> 80100470 init
> 8010049c init
> 8010352c kernel_thread
> 80100420 _stext
> 8010351c kernel_thread
>
>
> I wondered if anyone had any thoughts about what might be causing this, or
> had seen this occuring before - were there perhaps some changes made just
> after this point in time (now in the 2.5.x kernel)?
>
>
>
> Thanks.
>
>
>
>
^ permalink raw reply
* returning strings until no strings are left ?
From: J. @ 2002-12-16 20:46 UTC (permalink / raw)
To: linux-c-programming
In-Reply-To: <Pine.LNX.4.44.0212161043290.4841-100000@ns.isi.ulatina.ac.cr>
Hello,
I am new to c programming but not new to programming in general . The
``minor'' problem I keep running into at this moment:
I know how to return ONE string from a function. But what if I want to
keep returning strings from a function until there are no strings left to
return ? What should the function than return ? Because the function
should always return something in the end and of course the caller has to
know that the function is done or has nothing more to return .
for example fgets returns NULL when it's done, but if I try to return a
NULL at the end of my function while I claimed it as an char *... hmmzzz,
status epilepticus...
Thank you in advance...
J.
^ permalink raw reply
* Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Jun Sun @ 2002-12-16 20:40 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Ralf Baechle, linux-mips, jsun
In-Reply-To: <Pine.GSO.3.96.1021216140604.1430A-100000@delta.ds2.pg.gda.pl>
On Mon, Dec 16, 2002 at 02:44:38PM +0100, Maciej W. Rozycki wrote:
> On Sat, 14 Dec 2002, Ralf Baechle wrote:
>
> > > OCW3 defaults to IRR in our setup (as it does for the chip itself after
> > > writing ICWs) -- you need to select ISR explicitly before reading and
> > > reset it afterwards to avoid surprises. Unless we change the default for
> > > MIPS, which seems feasible -- we don't have to handle i386 oddities like
> > > I/O APICs and weird chipset bugs. And we avoid the need to grab a
> > > spinlock here. Alpha went this path.
> >
I actually meant to read IRR.
I had the code for a while. I remembered I was reading a i8259 programming
guide which recommands this method (perhaps for that MIPS board, which should
generally apply to other MIPS boards.). The idea is to read IRR to figure
out which interrupt you want to service and directly ack it and mask it.
This style fits more or less what we are doing with the rest of IRQ handling.
> > We don't have I/O APICs but there's a bunch of MIPS boxes that are based
> > on Intel chipsets plus glue logic so we may have to deal with some of the
> > same kind of bugs. And I'd not be surprised if the 8259 VHDL are coming
> > from the same source as the x86 ones so because I didn't want to tickle
> > the dragon's tail so I simply recycled the x86 code. Overly defensive?
> > Probably.
>
> Definitely -- the only place the IRR is used is the Neptune (i82378IB/ZB
> SIO, i82379AB SIO.A or i82374EB/SB ESC; one or more of them -- the note in
> arch/i386/kernel/time.c isn't detailed enough) i8254 core latch
> malfunction workaround. This is needed for do_slow_gettimeoffset(), which
> we do not need as we use the processor's internal timer for getting the
> offset (or are there any R3k-class systems with an Intel-style chipset?).
I don't think so.
> Even if we needed do_slow_gettimeoffset(),
No MIPS boards are using do_slow_gettimeoffset(). We really should get
rid of it.
> BTW, I thought on the code a bit and I discovered a few potential
> problems due to races. Handling them depends on the way acks are sent to
> i8259s -- Jun, could you please elaborate?
>
I am not sure which part you are referring to. The dispatch_i8259_irq() itself
is called from the first-level interrupt handling routine (assembly or in C),
running with interrupt disabled.
When you decide to service an i8259 IRQ, you move on to call do_IRQ(), still
with interrupt disabled. Pretty early in do_IRQ() we will do an ACK which will
clear the bit in IRR, before possibly later we turn on interrupt again.
Jun
^ permalink raw reply
* Re: linuxppc-commit mailing list
From: Hollis Blanchard @ 2002-12-16 20:39 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc embedded
In-Reply-To: <20021213163502.GK19456@opus.bloom.county>
On Fri, 2002-12-13 at 10:35, Tom Rini wrote:
> > If you aren't already on the linuxppc-commit@source.mvista.com list, you
> > might want to join that.
>
> And since this is at a possibly non obvious location:
> http://source.mvista.com/cgi-bin/mailman/listinfo/linuxppc-commit
>
> <hint>Hopefully PenguinPPC.org will have a link to this somewhere.</hint>
Actually it's already been linked to for a while (at
http://penguinppc.org/dev/kernel.shtml), but I've now made it more
obvious.
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ 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.