Re: [vox-tech] I'm also having ntp problems :-(
On Wednesday 24 April 2002 11:11 pm, [EMAIL PROTECTED] wrote: On Wed, Apr 24, 2002 at 11:04:01PM -0700, Ryan wrote: The following seems to be happening... connections to a udp server on nat work fine both ways. connections to a udp server on bob only work for sending data to bob. in tcpdump, I see nat telling bob that the udp port is unreachable, yet bob has no firewall. Very odd. Can you paste a 10 line tcpdump log showing this event? 23:18:56.151057 bob.ntp nat.ntp: [udp sum ok] v4 client strat 0 poll 4 prec -6 dist 1.00 disp 1.00 ref (unspec)@0.0 orig 0.0 rec -0.0 xmt -1066262965.417984008 (DF) (ttl 64, id 0, len 76) 23:18:56.151341 nat bob: icmp: nat udp port ntp unreachable for bob.ntp nat.ntp: v4 client strat 0 poll 4 prec -6 dist 1.00 disp 1.00 ref (unspec)@0.0 [|ntp] (DF) (ttl 64, id 0, len 76) [tos 0xc0] (ttl 255, id 20476, len 104) [repeated 3 times] A little background, nat is (the nat/firewall/ntp machine) bob is (the client) if not correct please explain. Yes, correct. nat's main job is to do NAT and firewall stuff. On Wednesday 24 April 2002 10:51 pm, [EMAIL PROTECTED] wrote: On Wed, Apr 24, 2002 at 10:26:13PM -0700, Ryan wrote: On Wednesday 24 April 2002 10:04 pm, [EMAIL PROTECTED] wrote: Something is preventing port 123 UDP packets from going between bob and nat, you can see packets be transmitted and no reply. It could also be that your ntpd is configured to not accept connections from bob. This can now be blamed on firewall rules. Something doesn't look right about this... Both ntdq and ntpdate create the same type of UDP based socket, running from the same machine one of them gets replies the other does not (the packets are different sizes). It is true that some length based firewall checks could be blocking the replies... but it's important to figure out what is broken before changing things and I still don't have enough information. It could be either ntpd or the firewall, since it could as likely be server configuration (like only accepting certain client revisions). If it still doesn't work after you have fun looking through your firewall rules install strace on the firewall and run the trace requested below. If you can't use apt-get install strace then remember it is simply one big executable, scp it to the firewall from a similar machine and just run the binary from /tmp then nuke it. ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] Debian X11 4.2 status...
On Wed, Feb 20, 2002 at 03:27:54PM -0800, Peter Jay Salzman wrote: unfortunately, afaics, debian sid still uses 4.1.0. if anyone knows of someone packaging a more recent X for debian, i'd like to know about it. For more explanation about 4.2 and debian see here... http://lists.debian.org/debian-devel/2002/debian-devel-200204/msg01343.html I haven't read the thread but the most amazing line from the first email... # I'm sure that with half an hour of manpage reading, a reasonably # intelligent person can learn everything he needs to produce XFree86 # 4.2 debs for himself that will work well enough I must be rock dumb... because I think he trimmed down things a bit, if you have someone point you directly at which pages are relevant and give you an overview it probably would only take a day to figure the build system out and know it well enough that you don't need to keep reading the documentation for step by step use. However there are a number of other hurdles required to package something like X which is to find it's true source, learn how to build it in the first place, and figure out how to configure for you own system. Maybe a after week a smart one could be transformed into a good for export X.deb building fiend... TTFN, Mike ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm also having ntp problems :-(
On Wed, Apr 24, 2002 at 11:21:56PM -0700, Ryan wrote: On Wednesday 24 April 2002 11:11 pm, [EMAIL PROTECTED] wrote: On Wed, Apr 24, 2002 at 11:04:01PM -0700, Ryan wrote: The following seems to be happening... connections to a udp server on nat work fine both ways. connections to a udp server on bob only work for sending data to bob. in tcpdump, I see nat telling bob that the udp port is unreachable, yet bob has no firewall. Very odd. Can you paste a 10 line tcpdump log showing this event? my bad, I kinda expect a verbose tcpdump... tcpdump -tteni eth0 -tt switches to a better time format, -e shows ethernet mac address info -n doesn't do name/server lookups so it's harder to hide errors. -i eth0 : you know this I would like a trace of the same even from both hosts bob and nat... since tcpdump's view of events is sometimes faked out by firewall rules on the machine running the dump (things it sees don't really happen on the wire). 23:18:56.151057 bob.ntp nat.ntp: [udp sum ok] v4 client strat 0 poll 4 prec -6 dist 1.00 disp 1.00 ref (unspec)@0.0 orig 0.0 rec -0.0 xmt -1066262965.417984008 (DF) (ttl 64, id 0, len 76) 23:18:56.151341 nat bob: icmp: nat udp port ntp unreachable for bob.ntp nat.ntp: v4 client strat 0 poll 4 prec -6 dist 1.00 disp 1.00 ref (unspec)@0.0 [|ntp] (DF) (ttl 64, id 0, len 76) [tos 0xc0] (ttl 255, id 20476, len 104) ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Debian X11 4.2 status...
begin [EMAIL PROTECTED] [EMAIL PROTECTED] On Wed, Feb 20, 2002 at 03:27:54PM -0800, Peter Jay Salzman wrote: unfortunately, afaics, debian sid still uses 4.1.0. if anyone knows of someone packaging a more recent X for debian, i'd like to know about it. For more explanation about 4.2 and debian see here... http://lists.debian.org/debian-devel/2002/debian-devel-200204/msg01343.html I haven't read the thread but the most amazing line from the first email... # I'm sure that with half an hour of manpage reading, a reasonably # intelligent person can learn everything he needs to produce XFree86 # 4.2 debs for himself that will work well enough jeez. i can't even package defendguin so that lintian doesn't complain about SOMETHING. i can only imagine packaging X. however, i suspect it would be possible to download the latest X cvs and use the debian/ directory from the debian package of X. might be do-able. huge undertaking though. i'd say it would cost an entire day. maybe more. that's probably one of the hardest things to package. pete ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] VGA Console Mode cursor bug.
Well, I've noticed that the demo machine has the following artifact: - when running the 2.4.18 kernel and - when the console is in standard VGA 80x25 resolution and - cursor is in column position 64, then a ghost of the cursor appears on line up and in column position 0. The effect is you have two blinking lines on the screen at one time. I suspect it is a video card problem. I haven't investigated this yet... more will follow when I figure out what's up. TTFN, Mike I switched from VESA console to VGA console mode at kernel compile time for a combination of the following reasons: - I can't *STAND* a blinking block cursor... I couldn't figure out how to slow the blink rate *or* change to a line cursor. - VESA mode is *dog* slow. - It's hard to read things 144 characters across - I'm not that impressed with the boot logo. I'm not against going back because I would like a nice fullscreen boot logo... if I can figure out how to slow or change the block cursor mode and speed up text mode... ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm also having ntp problems :-(
Well, after something like 16 months at the same IP, the ISP has decided to issue a new address to moria so DNS information is broken, and I'm not going to receive any email until it is fixed... worse yet if someone acquires the previous address email to me may begin to bounce. If anyone wondered why I started participating in vox-tech email it was because just a few days ago the DNS records were fixed, they had been broken for about 16 months which delayed mail to moria by over 24 hours most of the time. Sigh, Mike ...back to playing with debmirror. On Thu, Apr 25, 2002 at 02:31:49AM -0400, [EMAIL PROTECTED] wrote: On Wed, Apr 24, 2002 at 11:21:56PM -0700, Ryan wrote: On Wednesday 24 April 2002 11:11 pm, [EMAIL PROTECTED] wrote: On Wed, Apr 24, 2002 at 11:04:01PM -0700, Ryan wrote: ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] ac97 sound problems
mike, as always, this was a very informative post! i think i may have something to add. begin [EMAIL PROTECTED] [EMAIL PROTECTED] If you send a kill -9 and the process does not die instantly, then you have a kernel bug... there is no way to block or hide from kill -9. So you have a kernel bug. as you point out, processes in uninterruptable sleep can't be killed with SIGKILL. the process is put to sleep while the kernel waits for some event to happen. this corresponds to process status D. as you point out, it can be kernel bug. often a race condition. but it can also be caused by hardware failure. the chipset in question is known to have issues in both linux and windows. pete ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] ac97 sound problems
Kai,
I'm going to rearrange some things...
On Wed, Apr 24, 2002 at 09:15:51PM -0700, Kai Harris wrote:
1. the ac97 device driver is being loaded on startup:
Via 686a audio driver 1.9.1
ac97_codec: AC97 Audio codec, id: 0x414c:0x4710 (ALC200/200P)
via82cxxx: board #1 at 0xE800, IRQ 11
via_audio: ignoring drain playback error -11
Okay quick scan says that when the driver is being unloaded, it waits
around to play the last of the audio that is queued for the device.
If the device was open in non-blocking mode, then it will allow an
application to release the device before the buffer is really empty,
-11 or (-EAGAIN) i what it returns if this happens.
There is an obvious endless loop inside the kernel if the device was
opened in standard blocking mode and any audio was sent to it, and there
is something wrong... because the loop looks like the last chunk below.
The only reason your machine doesn't lock solid in this loop is there
is a schedule() call inside which allows the kernel to do something
else if it thinks there is something to do.
./drivers/sound/via82cxxx_audio.c
# * via_dsp_drain_playback - sleep until all playback samples are flushed
# *
# * Sleeps until all playback has been flushed to the audio
# * hardware.
/usr/include/asm/errno.h:
# #defineEAGAIN 11 /* Try again */
./drivers/sound/via82cxxx_audio.c
# for (;;) {
# __set_current_state(TASK_INTERRUPTIBLE);
# if (atomic_read (chan-n_frags) = chan-frag_number)
# break;
#
# if (nonblock) {
# DPRINTK (EXIT, returning -EAGAIN\n);
# ret = -EAGAIN;
# break;
# }
[...]
# }
4. top shows multiple copies of aRtsd running and I cannot kill them. They
continue to run after I log out of KDE and X and cannot be killed by their
owner (me), or by root. If I completely log out and then log in as root,
they are still running. One of these processes uses a significant amount of
CPU% (80-90%).
It seems to me that this is a very likely culprit. Is it possible for aRtsd
to bork so that it won't even respond to a kill signal? where would I go to
look for reasons for such a freeze?
aRtsd must open the device in blocking mode, combined with the code above
it explains the following...
The process that is using 90% of the CPU is the first one to open the
device and play the login greeting for KDE (or whatever)... since it sent
some audio to the device there is something in the buffer, which is trying
to be played but can't, so when aRtsd tried to close the device you hit
that endless kernel loop.
The reason the other processes are using none of the CPU is standard
kernel sound drivers create open once devices... the first open causes
anyone else to block waiting for the caller to close the device before
they can continue... if the first process exited *then* the others would
have a chance to go.
If you send a kill -9 and the process does not die instantly, then
you have a kernel bug... there is no way to block or hide from kill -9.
However, do not start killing things with -9, many programs have cleanup
operations they need to run when exiting, by using -9 they never get
to run their shutdown things, and that might mess up those programs on
the next start. So only try kill -9 on things that you tried a normal
kill and 5 seconds later they are still around.
So you have a kernel bug.
5. when playing an mp3 using mpg123 directly after a reboot, mpg123 plays
without returning an error message. however, there is no sound. Ctrl-c
mpg123 and run it again returns an error message:
audio: Resource temporarily unavailable
Something odd about this report is the
Resource temporarily unavailable message
is a EAGAIN thing, which you should only get if mpg123 opens something
non-blocking, the fact that when you hit cntl-c you get a prompt back
means that it is not hitting the same bug as above ... my copy mpg123
opens /dev/dsp in blocking mode so you might have another mpg123 variant.
It appears there might be another bug in the audio driver in that it
doesn't make the device available again to the next program after the
first closes.
2. the soundcard is setup as a module.
from /etc/modules.conf:
alias sound-slot-0 via82cxxx_audio
The dmesg output explains which drive you are using, this contains
nothing new. Good to include that file in bug reports though, so
people know nothing is wrong there.
6. Logging into X and KDE gives error message:
error: Error while initializing the sound driver:
device /dev/dsp can't be opened (Resource temporarily unavailable)
The sound server will continue, using the null output device
I do not know what to do. I have looked for help at the Mandrake Support
center and done multiple google
Tough nuts for kill -9 (was Re: [vox-tech] ac97 sound problems)
On Thu, 25 Apr 2002, Peter Jay Salzman wrote: mike, as always, this was a very informative post! i think i may have something to add. begin [EMAIL PROTECTED] [EMAIL PROTECTED] If you send a kill -9 and the process does not die instantly, then you have a kernel bug... there is no way to block or hide from kill -9. So you have a kernel bug. as you point out, processes in uninterruptable sleep can't be killed with SIGKILL. the process is put to sleep while the kernel waits for some event to happen. this corresponds to process status D. as you point out, it can be kernel bug. often a race condition. but it can also be caused by hardware failure. The process may also be a zombie... this has been discussed on this list and is a Unix FAQ ... http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC13 In such cases, you need to find and clean up the parent of the zombie and then wait a moment for the process table to get cleaned up. --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] ac97 sound problems
On Thu, Apr 25, 2002 at 11:05:43AM -0700, Peter Jay Salzman wrote: begin [EMAIL PROTECTED] [EMAIL PROTECTED] If you send a kill -9 and the process does not die instantly, then you have a kernel bug... there is no way to block or hide from kill -9. as you point out, processes in uninterruptable sleep can't be killed with SIGKILL. the process is put to sleep while the kernel waits for some event to happen. this corresponds to process status D. It is true that processes in state D don't die instantly, I had not considered them. Even processes in state D should die in a few seconds or _maybe_ a minute for a very slow device... but I can't think of any thing at the moment that is a _valid_ reason to lock a process in uninterruptable sleep forever. Realize that when the kernel exposes a method to become stuck forever in that state a malicious program can do great evil things to the machine by for example sucking up as much memory as possible and any other critical resources it can get, then calling the magic lock me method and the only way out would be a power cycle. Processes that get wedged in state D can also prevent the filesystems from unmounting... If you think of a few cases that locking the process is valid please let me know, I probably overlooked something... as you point out, it can be kernel bug. often a race condition. but it can also be caused by hardware failure. Most any hardware bugs can be worked around in software... The kernel is still alive and functioning, the driver knows how much data is queued on the device, it knows what data rate is being played and it could easily determine that the device has locked up... and reset the device. Most drivers will reset their devices when they detect a timeout or other shouldn't happen sort of error condition... if the device doesn't respond to the reset report that and return IO error messages to user space. A work around as drastic as blacklisting the buggy chipset is acceptable if the authors can't figure out how to dance around the problem. the chipset in question is known to have issues in both linux and windows. Hrmmm... I agree that I see reports of problems with the via chipsets even in the kernel documentation directory... /usr/src/linux/Documentation/sound/VIA-chipset saying that there was no word back from VIA but that file is ancient ... dated Jan 1999. I had heard via was much more active supporting linux, and now that I look further they appear to have step by step directions for enabling their chipsets in Linux... http://www.viaarena.com/?PageID=88 also public support forums available, possibly looking there would be another good place. Later, Mike ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: Tough nuts for kill -9 (was Re: [vox-tech] ac97 sound problems)
On Thu, Apr 25, 2002 at 12:36:02PM -0700, Jeff Newmiller wrote: On Thu, 25 Apr 2002, Peter Jay Salzman wrote: begin [EMAIL PROTECTED] [EMAIL PROTECTED] If you send a kill -9 and the process does not die instantly, then you have a kernel bug... there is no way to block or hide from kill -9. The process may also be a zombie... this has been discussed on this list and is a Unix FAQ ... Heh, zombie processes are already dead, which is why they can not be killed. On Linux all of their resources are released and they only occupy a few pages of memory for process state and return code, until their parent calls wait on them (which buries them). It's true that you can send them -9 and they will still appear in ps. Later, Mike ... in another bold statement all processes become zombies just after they exit. unless _maybe_ you are on a SMP machine... except maybe init, and all those those pesky kernel threads... ;) (I'm actually not certain of implementation, it could be that the kernel may suspend the process that exits, before cleaning up after it and flaging it as a Z state, to signal the parent... but that seems messy.) ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] Lugod Demo Computer Software suggestions?
People interested showing at the demo or who have some favorite pet
applications should speak-up now with what other applications should
be installed.
from an applicable legal disclaimer I've seen recently (quantum.com)
This file contains certain forward-looking statements. Actual results may
differ materially from the forward-looking statements contained herein.
Contents:
- Overview.
- Installed Debian package list. *
- Pruned kernel config.*
*: I was going to include the last two but that increases the size of the
message by about 70k, so I'll probably just send it to Bill and post
the URL.
Overview
Major installed packages include:
- X11 4.1, Gnome, KDE,
- Abiword, Gnumeric, Koffice, Openoffice,
- Mozilla, Konqueror, lynx, links
- Most of the development tool chain:
C, C++, Perl, Python,
- Many games:
nethack, tuxracer, defendguin, gemdropx, etc... ;)
the Loki demo archive... :{
Machine is running kernel 2.4.18, it has the following module
packs: alsa, i2c-sensors, lm-sensors. The kernel and module packs
are compiled into Debian packages in apt-getable /home/debian/local.
There is a local debian mirror of woody in /home/debian/mirror.
The machine is configured to apt-get from it's own mirror. The
mirror is updated every 24 hours via cron.
All three of the major X windows login systems are installed:
gdm, xdm, kdm. They are setup to start at boot on consoles
2, 3, 4. Once the graphics settle the machine should be at the
gdm login banner. Text consoles are running on 1,5-12.
==
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] ac97 sound problems
Mark, thanks for the advice on ALSA. I got that set up and it does work. On Wednesday 24 April 2002 11:59 pm, you wrote: I think I setup a Mandrake 8.2 on a system with ac97. Is your machine a Sony VAIO, slight purplish-silver color with a fold-out cover for the floppy? Is it a system with 2 USB connections on front as well as the back, got IEEE 1394-like connector with a disclaimer that it may not work with all 1394 devices? And it's got both DVD and CDRW? It also has a blue-LED power button that's long-thin-width shape on the front low-middle center? I've seen that system poping up everywhere these days; apparently it hit the sweet spot in price and power. No, I dont have this system. I put a new motherboard/processor (FIC AN11) in my old system. thanks again! Kai ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Lugod Demo Computer Software suggestions?
On Thursday 25 April 2002 13:03, [EMAIL PROTECTED] wrote: People interested showing at the demo or who have some favorite pet applications should speak-up now with what other applications should be installed Just a couple of suggestions: GnuCash Evolution Mozilla 1.0 RC1 (it just keeps getting better!) Mozilla plugins (Flash, Java, audio/video) -- Rod http://www.sunsetsystems.com/ ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] ac97 sound problems
begin [EMAIL PROTECTED] [EMAIL PROTECTED] On Thu, Apr 25, 2002 at 11:05:43AM -0700, Peter Jay Salzman wrote: begin [EMAIL PROTECTED] [EMAIL PROTECTED] If you send a kill -9 and the process does not die instantly, then you have a kernel bug... there is no way to block or hide from kill -9. as you point out, processes in uninterruptable sleep can't be killed with SIGKILL. the process is put to sleep while the kernel waits for some event to happen. this corresponds to process status D. It is true that processes in state D don't die instantly, I had not considered them. Even processes in state D should die in a few seconds or _maybe_ a minute for a very slow device... but I can't think of any thing at the moment that is a _valid_ reason to lock a process in uninterruptable sleep forever. state D processes *can* last forever. do a google group search on uninterruptable sleep (after you correct my spelling of uninterruptable which i no doubt got wrong). but putting aside google groups, *i've* seen state D processes last for weeks on my system. they only died after a reboot. you can certainly imagine a trivial scenario for such a thing -- consider a process which is waiting for a data page coming from swap. no data page, no scheduling. it's as simple as that. and signals won't help here -- you can't signal a process hey, i just read your data, here it is. what you do is you put the process to sleep until the event occurs. if that happens to be an open() or write() for a user space process, then that process is stuck. Realize that when the kernel exposes a method to become stuck forever in that state a malicious program can do great evil things to the machine by for example sucking up as much memory as possible and any other critical resources it can get, then calling the magic lock me method and the only way out would be a power cycle. maybe i'm not understanding you, but it sounds like this is a non-issue. a process which is in uninterruptable sleep is simply placed on a wait queue and not scheduled at all if you want to talk about evil stuff, then ... well sure. ALL kernel code is trusted code, starting with a simple call to printk() to code that modifies system calls. they ALL present dr. evil with the opportunity to wreak havoc. you certainly don't need a state D process for that! Processes that get wedged in state D can also prevent the filesystems from unmounting... sure. but *any* part of the kernel can put itself to sleep. it's as simple as passing a macro to a function call. If you think of a few cases that locking the process is valid please let me know, I probably overlooked something... well, i just gave one. but here's another. suppose you're some kernel code and you're waiting for some event to happen, so you put yourself to sleep. but suppose the event occurs AFTER you decide to put yourself to sleep but BEFORE you actually do go to sleep. poorly written code won't recover from this type of race condition. and then we need to debate whether poorly written code is a bug. as you point out, it can be kernel bug. often a race condition. but it can also be caused by hardware failure. Most any hardware bugs can be worked around in software... heh. ok, i'm willing to concede this point, but only because we're talking about symantics now. is not supporting a hardware bug considered a kernel bug? maybe. maybe not. there's nearly an infinite number of things bad hardware can do. should the kernel have a work around for all of them? all possible conceivable crazy things hardware can do? this isn't quite as simple as a switch that tests the value of an integer. should we call code buggy if it doesn't address all possible circumstances? i dunno! The kernel is still alive and functioning, the driver knows how much data is queued on the device, it knows what data rate is being played and it could easily determine that the device has locked up... and reset the device. Most drivers will reset their devices when they detect a timeout or other shouldn't happen sort of error condition... if the device doesn't respond to the reset report that and return IO error messages to user space. A work around as drastic as blacklisting the buggy chipset is acceptable if the authors can't figure out how to dance around the problem. exactly. the chipset in question is known to have issues in both linux and windows. Hrmmm... I agree that I see reports of problems with the via chipsets even in the kernel documentation directory... /usr/src/linux/Documentation/sound/VIA-chipset saying that there was no word back from VIA but that file is ancient ... dated Jan 1999. I had heard via was much more active supporting linux, and now that I look further they appear to have step by step directions for enabling their chipsets in Linux... http://www.viaarena.com/?PageID=88 also
Re: [vox-tech] ac97 sound problems
Mike,
thanks for all the info! however, working on possible kernel bugs and even
driver bugs is WAY over my head! i will submit a bug report to the via8233
driver maintainer though.
i have gotten ALSA up and running thoughi can finally listen to some
music.
Kai
On Thursday 25 April 2002 10:50 am, you wrote:
Kai,
I'm going to rearrange some things...
On Wed, Apr 24, 2002 at 09:15:51PM -0700, Kai Harris wrote:
1. the ac97 device driver is being loaded on startup:
Via 686a audio driver 1.9.1
ac97_codec: AC97 Audio codec, id: 0x414c:0x4710 (ALC200/200P)
via82cxxx: board #1 at 0xE800, IRQ 11
via_audio: ignoring drain playback error -11
Okay quick scan says that when the driver is being unloaded, it waits
around to play the last of the audio that is queued for the device.
If the device was open in non-blocking mode, then it will allow an
application to release the device before the buffer is really empty,
-11 or (-EAGAIN) i what it returns if this happens.
There is an obvious endless loop inside the kernel if the device was
opened in standard blocking mode and any audio was sent to it, and there
is something wrong... because the loop looks like the last chunk below.
The only reason your machine doesn't lock solid in this loop is there
is a schedule() call inside which allows the kernel to do something
else if it thinks there is something to do.
./drivers/sound/via82cxxx_audio.c
# * via_dsp_drain_playback - sleep until all playback samples are
flushed # *
# * Sleeps until all playback has been flushed to the audio
# * hardware.
/usr/include/asm/errno.h:
# #defineEAGAIN 11 /* Try again */
./drivers/sound/via82cxxx_audio.c
# for (;;) {
# __set_current_state(TASK_INTERRUPTIBLE);
# if (atomic_read (chan-n_frags) = chan-frag_number)
# break;
#
# if (nonblock) {
# DPRINTK (EXIT, returning -EAGAIN\n);
# ret = -EAGAIN;
# break;
# }
[...]
# }
4. top shows multiple copies of aRtsd running and I cannot kill them.
They continue to run after I log out of KDE and X and cannot be killed by
their owner (me), or by root. If I completely log out and then log in as
root, they are still running. One of these processes uses a significant
amount of CPU% (80-90%).
It seems to me that this is a very likely culprit. Is it possible for
aRtsd to bork so that it won't even respond to a kill signal? where
would I go to look for reasons for such a freeze?
aRtsd must open the device in blocking mode, combined with the code above
it explains the following...
The process that is using 90% of the CPU is the first one to open the
device and play the login greeting for KDE (or whatever)... since it sent
some audio to the device there is something in the buffer, which is trying
to be played but can't, so when aRtsd tried to close the device you hit
that endless kernel loop.
The reason the other processes are using none of the CPU is standard
kernel sound drivers create open once devices... the first open causes
anyone else to block waiting for the caller to close the device before
they can continue... if the first process exited *then* the others would
have a chance to go.
If you send a kill -9 and the process does not die instantly, then
you have a kernel bug... there is no way to block or hide from kill -9.
However, do not start killing things with -9, many programs have cleanup
operations they need to run when exiting, by using -9 they never get
to run their shutdown things, and that might mess up those programs on
the next start. So only try kill -9 on things that you tried a normal
kill and 5 seconds later they are still around.
So you have a kernel bug.
5. when playing an mp3 using mpg123 directly after a reboot, mpg123
plays without returning an error message. however, there is no sound.
Ctrl-c mpg123 and run it again returns an error message:
audio: Resource temporarily unavailable
Something odd about this report is the
Resource temporarily unavailable message
is a EAGAIN thing, which you should only get if mpg123 opens something
non-blocking, the fact that when you hit cntl-c you get a prompt back
means that it is not hitting the same bug as above ... my copy mpg123
opens /dev/dsp in blocking mode so you might have another mpg123 variant.
It appears there might be another bug in the audio driver in that it
doesn't make the device available again to the next program after the
first closes.
2. the soundcard is setup as a module.
from /etc/modules.conf:
alias sound-slot-0 via82cxxx_audio
The dmesg output explains which drive you are using, this contains
nothing new. Good to include that file in bug reports though, so
people know nothing is
[vox-tech] Environmental Variables
Hi, What is the correct syntax to set/change environmental variable in Linux (RedHat 7.2)? For example for the variable $DISPLAY, is it xterm -display $DISPLAY or setenv DISPLAY $DISPLAY? Is there a man page that explains this? Thanks! Alfredo ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Lugod Demo Computer Software suggestions?
(This should really be on VOX, but... whatever :^) )
On Thu, Apr 25, 2002 at 04:03:10PM -0400, [EMAIL PROTECTED] wrote:
snip
Overview
Major installed packages include:
- X11 4.1, Gnome, KDE,
- Abiword, Gnumeric, Koffice, Openoffice,
- Mozilla, Konqueror, lynx, links
- Most of the development tool chain:
C, C++, Perl, Python,
- Many games:
nethack, tuxracer, defendguin, gemdropx, etc... ;)
the Loki demo archive... :{
Add to this:
The Gimp ( www.gimp.org )
XMMS ( www.xmms.org )
Some XMMS visualization plug-ins ( )
And, if you have time,
Frozen Bubble ( www.frozen-bubble.org - avail. as .deb )
glTron( www.gltron.org )
FlightGear( www.flightgear.org )
Vectoroids [ ;) ]( www.newbreedsoftware.com/vectoroids/ )
Asteroids 3D ( www.psc.edu/~smp/a3d/ )
XVNC [*] ( www.uk.research.att.com/vnc/xvnc.html )
And make sure sound is working! :) (If you don't have speakers, you can
always use headphones, ya know!)
[*] It'd be cool to show the Zaurus over VNC at the demos.
I may need a little help getting a network between the systems...
Thanks for your work!
I've updated the Demo Box page:
http://www.lugod.org/projects/demo/computer.php
-bill!
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] unkillable processes (was: ac97 sound problems)
On Thu, Apr 25, 2002 at 11:05:43AM -0700, Peter Jay Salzman wrote: [...] as you point out, processes in uninterruptable sleep can't be killed with SIGKILL. the process is put to sleep while the kernel waits for some event to happen. this corresponds to process status D. as you point out, it can be kernel bug. often a race condition. but it can also be caused by hardware failure. I have seen such unkillable processes crop up on NFS clients, in cases of server failure. -- Henry House The attached file is a digital signature. See http://romana.hajhouse.org/pgp for information. My OpenPGP key: http://romana.hajhouse.org/hajhouse.asc. msg02366/pgp0.pgp Description: PGP signature
Re: [vox-tech] Anyone got encrypted fs on mdk8.2 working?
On Wed, Apr 24, 2002 at 09:07:12PM -0700, Ryan wrote: Blasted thing won't take my password, I tried formating the partition a few times, didn't help. Anyone using this wanna share? Interesting. Do you know what kernel driver is being used? I may know about it, since I researched cryptographic filesystems for a talk a year or two ago. -- Henry House The attached file is a digital signature. See http://romana.hajhouse.org/pgp for information. My OpenPGP key: http://romana.hajhouse.org/hajhouse.asc. msg02367/pgp0.pgp Description: PGP signature
Re: [vox-tech] Lugod Demo Computer Software suggestions?
On Thu, Apr 25, 2002 at 01:20:52PM -0700, Rod Roark wrote: Just a couple of suggestions: GnuCash Evolution done. Mozilla 1.0 RC1 (it just keeps getting better!) Mozilla plugins (Flash, Java, audio/video) 0.9.9 is packaged and installed. I'll dig around for 1.0 once it's finalized. Java is in. Installed libflash, I find some flash overloaded sites annoying. Dunno what you mean by audio/video. I'll worry about this stuff after the sound card is working. On Thu, Apr 25, 2002 at 02:04:54PM -0700, nbs wrote: (This should really be on VOX, but... whatever :^) ) true... but I'm not on vox. ;) On Thu, Apr 25, 2002 at 04:03:10PM -0400, [EMAIL PROTECTED] wrote: The Gimp ( www.gimp.org ) XMMS ( www.xmms.org ) Some XMMS visualization plug-ins ( ) XVNC [*] ( www.uk.research.att.com/vnc/xvnc.html ) And, if you have time, Frozen Bubble ( www.frozen-bubble.org - avail. as .deb ) glTron( www.gltron.org ) FlightGear( www.flightgear.org ) Vectoroids [ ;) ]( www.newbreedsoftware.com/vectoroids/ ) done. Asteroids 3D ( www.psc.edu/~smp/a3d/ ) not packaged, or I'm missing it. ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Lugod Demo Computer Software suggestions?
Mike said: Bill said: The Gimp ( www.gimp.org ) XMMS ( www.xmms.org ) Some XMMS visualization plug-ins ( ) XVNC [*] ( www.uk.research.att.com/vnc/xvnc.html ) And, if you have time, Frozen Bubble ( www.frozen-bubble.org - avail. as .deb ) glTron( www.gltron.org ) FlightGear( www.flightgear.org ) Vectoroids [ ;) ]( www.newbreedsoftware.com/vectoroids/ ) done. All of them? Cool! Thanks! Asteroids 3D ( www.psc.edu/~smp/a3d/ ) not packaged, or I'm missing it. No prob. I've never actually tried it before, so I don't even know if it's good. LOOKS nifty. There's another cool 3D asteroid game out there, too (not 1st person) -bill! ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Lugod Demo Computer Software suggestions?
Also, what servers are installed? (I assume Apache - what's enabled? OpenSSH, too, I'm presume. Anything else?) -bill! ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: Tough nuts for kill -9 (was Re: [vox-tech] ac97 sound problems)
On Thu, 25 Apr 2002 [EMAIL PROTECTED] wrote: On Thu, Apr 25, 2002 at 12:36:02PM -0700, Jeff Newmiller wrote: On Thu, 25 Apr 2002, Peter Jay Salzman wrote: begin [EMAIL PROTECTED] [EMAIL PROTECTED] If you send a kill -9 and the process does not die instantly, then you have a kernel bug... there is no way to block or hide from kill -9. The process may also be a zombie... this has been discussed on this list and is a Unix FAQ ... Heh, zombie processes are already dead, which is why they can not be killed. On Linux all of their resources are released and they only occupy a few pages of memory for process state and return code, until their parent calls wait on them (which buries them). I know, and you know, but this is not intuitively obvious to someone who doesn't know, so it is worth mentioning BEFORE concluding that they are dealing with kernel bugs. It's true that you can send them -9 and they will still appear in ps. Later, Mike ... in another bold statement all processes become zombies just after they exit. unless _maybe_ you are on a SMP machine... except maybe init, and all those those pesky kernel threads... ;) When a process exits its parent may be waiting for it. I don't have time (and no guarantee I can succeed when I do) to dig into the kernel and see if this case is recognized and optimized out, but I would hope it is. (I'm actually not certain of implementation, it could be that the kernel may suspend the process that exits, before cleaning up after it and flaging it as a Z state, to signal the parent... but that seems messy.) Something to look at sometime... --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] unkillable processes (was: ac97 sound problems)
On Thu, Apr 25, 2002 at 03:10:28PM -0700, Henry House wrote: On Thu, Apr 25, 2002 at 11:05:43AM -0700, Peter Jay Salzman wrote: [...] as you point out, processes in uninterruptable sleep can't be killed with SIGKILL. the process is put to sleep while the kernel waits for some event to happen. this corresponds to process status D. as you point out, it can be kernel bug. often a race condition. but it can also be caused by hardware failure. I have seen such unkillable processes crop up on NFS clients, in cases of server failure. Henry, Very true... a valid example of an unkillable process (which is not a kernel bug and is not a zombie ;). Any other examples? That is related to NFS hard mounts. (The process will wake as soon as the NFS server becomes reachable and completes the pending request, if you kill the process while it is waiting, the process will die the second whatever write operation it was doing completes). cut and pasted from part of a off channel thread: === The _only_ exception of where a long uninterruptable sleep is acceptable is for NFS mounted files when the machine has lost access to it's file server, this is because NFS by default will retry indefinitely for the server to return, it is possible to soft or intr mount with to disable this feature... even hard mounts can be force unmounted by root which should wake all affected processes. ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Lugod Demo Computer Software suggestions?
On Thu, Apr 25, 2002 at 03:14:57PM -0700, nbs wrote: All of them? Cool! Thanks! Yes, it only takes a few seconds to run apt-cache search on the packages you mention (to find their true package names) then do a apt-get install on the list of names. Asteroids 3D ( www.psc.edu/~smp/a3d/ ) not packaged, or I'm missing it. No prob. But when it's not packaged then I'd need to go find the source, figure out how to compile it and junk, which could take an hour for each package. ;) ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Lugod Demo Computer Software suggestions?
On Thu, Apr 25, 2002 at 06:58:19PM -0400, [EMAIL PROTECTED] wrote: not packaged, or I'm missing it. No prob. But when it's not packaged then I'd need to go find the source, figure out how to compile it and junk, which could take an hour for each package. ;) No ... I didn't mean It is not a problem for you to install it, lazybones I meant It is not a problem that you didn't bother installing it - it's not NECESSARY :) Anyway, thanks again! Also, I made all app. titles on the Demo Computer page on LUGOD.org links to their various homepages. (Most are www.[name of program].org :) ) -bill! ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Thu, Apr 25, 2002 at 04:23:30PM -0700, Chris McKenzie wrote: Also, be aware of symmetric versus assymetric processes and processes that require you to have something or know something. Assymetric processes that require you to have or know something are usually preferred. Chris, The two sentences above lost me. Could you explain a little more what context you are talking about... I've not heard the phrases: symmetric processes, assymetric processes, processes that require you to have or know something... Thanks, Mike my spell checker says asymmetric ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm also having ntp problems :-(
On Wednesday 24 April 2002 11:31 pm, [EMAIL PROTECTED] wrote: my bad, I kinda expect a verbose tcpdump... tcpdump -tteni eth0 -tt switches to a better time format, -e shows ethernet mac address info -n doesn't do name/server lookups so it's harder to hide errors. -i eth0 : you know this I would like a trace of the same even from both hosts bob and nat... since tcpdump's view of events is sometimes faked out by firewall rules on the machine running the dump (things it sees don't really happen on the wire). [root@bob root]# tcpdump -ttne tcpdump: listening on eth0 1019784403.866888 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784403.867759 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] 1019784404.866821 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784404.867643 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] 1019784405.866835 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784405.867660 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] 1019784406.866822 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784406.867643 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] [root@nat root]# tcpdump -ttne tcpdump: listening on eth0 1019784406.612164 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784406.612481 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] 1019784407.611976 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784407.612251 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] 1019784408.611880 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784408.612151 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] 1019784409.611749 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784409.612021 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] in playing with things some more, I can't get nat to connect to ANY services on bob... ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
Sure, I wasn't trying to intend a pun, I just mispelled. ok. I will give you examples for have and know. Being carded before buying alcohol is a process that requires you to have ID as opposed to buying anything else in which case it only requires you to have money. If you don't have it, money/id, whatever, then you cannot complete the process. Sometimes, having is not good enough however. For you ATM card, not only do you need to have the card but you need to know the pin to access your account at the ATM. This is so someone that has a pin and not the card or visa versa can't do top much (ideally). Computer login can be the same. I can restrict login to be from a list of friendly computers. So you have to first have access to the friendly computers then know the login on the system, simply having access to the friendly computeris not enough and simply knowing the login is not enough. Microsoft displays a horrible implementation of this with registration keys. Not only do you need to have the software but you need to know this long incoherent string of characters which you can get from most friends and easily with internet access. The .NET will eliminate one of these. After it is implemented then either the computer itself must be uniquely identified somehow as something you have or you must uniquely be identified somehow through fingerprints or something like that. This would be coupled with something you know, a login/password pair probably. Asymmetric/Symmetric processes. A Symmetric Process is something that is reversible, like a ball bouncing, if you reverse a video of someone bouncing a ball you might not be able to tell which way is forward and which way is backward. However if someone breaks some crystal on the ground then it is very distinct because crystal magically reassembling itself to some dove shape is not a normal occurance. And if you were to reassemble the shattered crystals (it is possible given a lot of time and effort) There would be only one way to do it. And a major clue of how to do it depends on what it looked like initially. In comes almost modern encryption Pretend that you had some fantastic device that could figure out how the crystal breaks and it some how magnificantly tracks every piece of the crystal, then you throw the pieces into this mystical machine and the crystal is reassembled. It would be easy to assume that the device for putting the crystal back together would be much more difficult then a device for taking it apart, say a hammer. This process is nearly-asymmetric. Although it is much more difficult to do the reverse it is still possible, and in fact, it is the same process in reverse as long as you know how it broke although a different procedure. An example of this in real life is a door. The magnificant machine in this case is something I have, a key. I put it in the lock and turn, simple enough, the door no longer opens. Some nefarious person comes along and uses some much much more sophisticated device and reverses the process. Because what I did is quite difficult to undo without something I have or know, it is somewhat secure. This is essentially how modern algorithms work. Modern encryption, assymetric processes. Alright, say I had a very rare piece of software, OpenStep 4.2/i386 and I wanted to send it to you. However, you live in some remote jungle where you can't copy a key. But I don't want the item to be stolen along the way. So I put a lock on the box and send it to you. You can't open that lock so in a ridiculous notion, you put another lock on it, one that you have the key for and send the doubly locked box back to me. I unlock my lock but the box is still locked by you. I send it back, and you unlock your lock and have the software. By the same idea, I can come up with some very sophisticated lock -- one Dr Seuss would be proud to put in a book. I design it in such a way so that whenever you lock the lock the lock is designed in such a way that you need a different key to unlock it. Ah, this is the asymmetric part -- if someone wanted to unlock it, reversing what they just did was not enough because it is some mystical lock that must be unlocked by a different process. Thus I can give out these locks and the locking keys freely and say if you want to send me anything throw my lock on it and lock it. I have the only key to unlock it. An example of an asymmetric process in nature is a chemical reaction. Say I throw two chemicals together and they bond and turn green. How would I seperate them? I definitely can't go in there and break the bonds by hand...more than likely, I may have to do something entirely different, say make the chemical some scorching temperature to get what I started with. Perhaps I may get three different chemicals as a result of this. Then I may have to combine two to get my original two chemicals 0 Symmetric is where doing
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
begin Chris McKenzie [EMAIL PROTECTED] Sure, I wasn't trying to intend a pun, I just mispelled. Modern encryption, assymetric processes. Alright, say I had a very rare piece of software, OpenStep 4.2/i386 and I wanted to send it to you. However, you live in some remote jungle where you can't copy a key. But I don't want the item to be stolen along the way. So I put a lock on the box and send it to you. You can't open that lock so in a ridiculous notion, you put another lock on it, one that you have the key for and send the doubly locked box back to me. I unlock my lock but the box is still locked by you. I send it back, and you unlock your lock and have the software. hi chris, cool post. this isn't how modern crypto systems work, is it? this assumes that the locks commute. that for a given message A, a chris lock C and peter lock P: chris CA -- peter PCA -- chris C^(-1)PCA -- peter P^(-1)C^(-1)PCA but i can't actually unlock the software unless P^(-1)C^(-1) = C^(-1)P^(-1) i don't know much about modern crypto systems other than RSA type things. is this how they work? or am i reading too much into an analogy? also, i could be totally way off base here, but i think you and mike were talking about different types of processes. i'm pretty sure mike is familiar with reversible processes. i'm guessing he thought you meant something that goes into a process table. (?) pete ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
Interesting, I never thought about that before. The locking (and corresponding unlocking) could easily be done by xor'ing against some string of pseudo-random characters that only the encryptor knows how to produce. -- Rod http://www.sunsetsystems.com/ On Thursday 25 April 2002 07:13 pm, Peter Jay Salzman wrote: begin Chris McKenzie [EMAIL PROTECTED] Sure, I wasn't trying to intend a pun, I just mispelled. Modern encryption, assymetric processes. Alright, say I had a very rare piece of software, OpenStep 4.2/i386 and I wanted to send it to you. However, you live in some remote jungle where you can't copy a key. But I don't want the item to be stolen along the way. So I put a lock on the box and send it to you. You can't open that lock so in a ridiculous notion, you put another lock on it, one that you have the key for and send the doubly locked box back to me. I unlock my lock but the box is still locked by you. I send it back, and you unlock your lock and have the software. hi chris, cool post. this isn't how modern crypto systems work, is it? this assumes that the locks commute. that for a given message A, a chris lock C and peter lock P: chris CA -- peter PCA -- chris C^(-1)PCA -- peter P^(-1)C^(-1)PCA but i can't actually unlock the software unless P^(-1)C^(-1) = C^(-1)P^(-1) i don't know much about modern crypto systems other than RSA type things. is this how they work? or am i reading too much into an analogy? also, i could be totally way off base here, but i think you and mike were talking about different types of processes. i'm pretty sure mike is familiar with reversible processes. i'm guessing he thought you meant something that goes into a process table. (?) pete ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Thu, 25 Apr 2002, Rod Roark wrote: Interesting, I never thought about that before. The locking (and corresponding unlocking) could easily be done by xor'ing against some string of pseudo-random characters that only the encryptor knows how to produce. The most advanced encryption available is found when you use 2XOR (double-XOR) with your data and the same key. You also get a huge cost savings in performance, as some stes can be skipped and, 8 bit 2XOR is just as secure as 2048bit 2XOR (assuming the same key in both passes. (Tongue in cheek - biteing down hard.) (This would have been better posted April, 1,2002 ;-) -ME -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-) C++$() U$(+$) P+$+++ L+++$(++) E W+++$(+) N+ o K w+$+ O-@ M+$ V-$- !PS !PE Y+ !PGP t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+++ h(++)+ r*? z? --END GEEK CODE BLOCK-- decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Thu, 25 Apr 2002, ME wrote: On Thu, 25 Apr 2002, Rod Roark wrote: Interesting, I never thought about that before. The locking (and corresponding unlocking) could easily be done by xor'ing against some string of pseudo-random characters that only the encryptor knows how to produce. The most advanced encryption available is found when you use 2XOR (double-XOR) with your data and the same key. You also get a huge cost savings in performance, as some stes can be skipped and, 8 bit 2XOR is just as secure as 2048bit 2XOR (assuming the same key in both passes. (Tongue in cheek - biteing down hard.) (This would have been better posted April, 1,2002 ;-) -ME Ouch... ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Thu, Apr 25, 2002 at 08:47:34PM -0700, ME wrote: The most advanced encryption available is found when you use 2XOR (double-XOR) with your data and the same key. Like those ebooks! Wait, no that was ROT13 -bill! ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Lugod Demo Computer Software suggestions?
You probably already have this set up on the computer and just forgot to mention it in
the
overview, but the computer needs to act as a DHCP server at Installfests so we can set
up
computers for DHCP networking and not have to wait for two minutes each time as we
restart
computers repeatedly while we are troubleshooting them.
Since I'm sure the woody mirror is also intended for Installfests, DHCP would help
greatly for
that too.
--- ORIGINAL MESSAGE ---
Date: Thu, 25 Apr 2002 16:03:10 -0400
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [vox-tech] Lugod Demo Computer Software suggestions?
Reply-To: [EMAIL PROTECTED]
Contents:
- Overview.
- Installed Debian package list. *
- Pruned kernel config.*
*: I was going to include the last two but that increases the size of the
message by about 70k, so I'll probably just send it to Bill and post
the URL.
Overview
Major installed packages include:
- X11 4.1, Gnome, KDE,
- Abiword, Gnumeric, Koffice, Openoffice,
- Mozilla, Konqueror, lynx, links
- Most of the development tool chain:
C, C++, Perl, Python,
- Many games:
nethack, tuxracer, defendguin, gemdropx, etc... ;)
the Loki demo archive... :{
Machine is running kernel 2.4.18, it has the following module
packs: alsa, i2c-sensors, lm-sensors. The kernel and module packs
are compiled into Debian packages in apt-getable /home/debian/local.
There is a local debian mirror of woody in /home/debian/mirror.
The machine is configured to apt-get from it's own mirror. The
mirror is updated every 24 hours via cron.
All three of the major X windows login systems are installed:
gdm, xdm, kdm. They are setup to start at boot on consoles
2, 3, 4. Once the graphics settle the machine should be at the
gdm login banner. Text consoles are running on 1,5-12.
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Thursday 25 April 2002 09:43 pm, nbs wrote: Like those ebooks! Wait, no that was ROT13 not ROT26? -bill! ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Lugod Demo Computer Software suggestions?
I suggested a similar idea a while back and Peter volunteered me to setup
my laptop has the DHCP server at IFs. I've been to every single one of
the IFs with my DHCP-ready laptop ever since... unless I couldn't make it
for some reason (translation: done it once.)
-Mark
On Thu, 25 Apr 2002, Ken Bloom wrote:
You probably already have this set up on the computer and just forgot to mention it
in the
overview, but the computer needs to act as a DHCP server at Installfests so we can
set up
computers for DHCP networking and not have to wait for two minutes each time as we
restart
computers repeatedly while we are troubleshooting them.
Since I'm sure the woody mirror is also intended for Installfests, DHCP would help
greatly for
that too.
--- ORIGINAL MESSAGE ---
Date: Thu, 25 Apr 2002 16:03:10 -0400
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [vox-tech] Lugod Demo Computer Software suggestions?
Reply-To: [EMAIL PROTECTED]
Contents:
- Overview.
- Installed Debian package list. *
- Pruned kernel config.*
*: I was going to include the last two but that increases the size of the
message by about 70k, so I'll probably just send it to Bill and post
the URL.
Overview
Major installed packages include:
- X11 4.1, Gnome, KDE,
- Abiword, Gnumeric, Koffice, Openoffice,
- Mozilla, Konqueror, lynx, links
- Most of the development tool chain:
C, C++, Perl, Python,
- Many games:
nethack, tuxracer, defendguin, gemdropx, etc... ;)
the Loki demo archive... :{
Machine is running kernel 2.4.18, it has the following module
packs: alsa, i2c-sensors, lm-sensors. The kernel and module packs
are compiled into Debian packages in apt-getable /home/debian/local.
There is a local debian mirror of woody in /home/debian/mirror.
The machine is configured to apt-get from it's own mirror. The
mirror is updated every 24 hours via cron.
All three of the major X windows login systems are installed:
gdm, xdm, kdm. They are setup to start at boot on consoles
2, 3, 4. Once the graphics settle the machine should be at the
gdm login banner. Text consoles are running on 1,5-12.
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
--
Mark K. Kim
http://www.cbreak.org/
PGP key available upon request.
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm also having ntp problems :-(
On Thu, Apr 25, 2002 at 06:36:47PM -0700, Ryan wrote: in playing with things some more, I can't get nat to connect to ANY services on bob... Cool, based on that last trace one or two things is happening: - You have no process listing to UDP port 123 on nat - Your firewall rules on nat are rejecting UDP traffic to port 123. The strace of ntpd would finalize the problem, but it looks like you have a firewall rule filtering out the traffic. ;) ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
