>> good for today and future ladmins that cannot type a command.
>>
>> Any USEFUL proposals that add some real functionality?
>
> Since this will enable more people to run FreeBSD that otherwise
> wouldn't give it a second glance, I would say it is VERY useful.
Really? How useful is FreeBSD going
Wojciech writes:
> after reading quite recent topics about disabling/enabling write cache, i
> tried to test in on desktop 3.5" drive
>
> kern.cam.ada.write_cache: 1
> kern.cam.ada.read_ahead: 1
> kern.cam.ada.0.read_ahead: -1
> kern.cam.ada.0.write_cache: -1
>
> i tried writing 1 or 0 to kern.cam.
[ This topic is better discussed in -multimedia@, suggest that followups
drop -hackers@ ]
> i am out of current knowledge about common TV for about 10 years.
>
> Currently in Poland there is aerial TV broadcasted in DVB-T standard.
> There are TVs with builtin decoder/demodulator or separate
> dec
Stefan writes:
> I seem to remember, that drives of that time required the write cache
> to be enabled to get any speed-up from tagged commands. This was no
> risk with SCSI drives, since the cache did not make the drives lye
> about command completion (i.e. the status for the write was only
> retu
Matthew writes:
> There is also no information in the original email as to which direction
> the I/O was being sent.
In one of the followups, Karim reported:
# dd if=/dev/zero of=foo count=10 bs=1024000
10+0 records in
10+0 records out
1024 bytes transferred in 19.615134 secs (522046 b
Scott writes:
> If I had my way, the WC would be off, everyone would be using SAS,
> and anyone who enabled SATA WC or complained about I/O slowness
> would be forced into Siberian salt mines for the remainder of their lives.
Actually, If you are running SAS, having SATA WC on or off wouldn't
matt
Wojciech writes:
> If computer have UPS then write caching is fine. even if FreeBSD crash,
> disk would write data
That is incorrect. A UPS reduces the risk, but does not eliminate it.
It is impossible to completely eliminate the risk of having the
write cache on. If you care about your data you
> I am thinking that something fancy in that SAS drive is
> not being handled correctly by the FreeBSD driver.
I think so too, and I think the something fancy is "tagged command queuing".
The driver prints "da0: Command Queueing enabled" and yet your SAS drive
is only getting 1 write per rev, and
Karim writes:
> It is quite obvious that something is awfully slow on SAS drives,
> whatever it is and regardless of OS comparison. We swapped the SAS
> drives for SATA and we're seeing much higher speeds. Basically on par
> with what we were expecting (roughly 300 to 400 times faster then what
> w
> 25.9 MB/s
Even Linux is pretty slow.
> Transfer rates:
> outside: 102400 kbytes in 0.685483 sec = 149384 kbytes/sec
> middle:102400 kbytes in 0.747424 sec = 137004 kbytes/sec
> inside:102400 kbytes in 1.051036 sec = 97428 kbytes/sec
That's mo
I wrote:
> The kernel must be doing write-behind even to a raw disk, otherwise
> waiting for write(2) to return before issuing the next write would
> slow it down as Matthew suggests.
And a minute after hitting send, I remembered that FreeBSD does not
provide the traditional "raw" disk devices, e.
Karim writes:
> dd to the
> raw drive and no compression/encryption or some other features, just a
> naive boot off a live 9.1 CD then dd (see below). The following results
> have been gathered on the FreeBSD 9.1 system:
>
> # dd if=/dev/zero of=toto count=100
> 100+0 records in
> 100+0 records out
Domagoj writes:
> I've attempted to grep '/usr/ports/*/*/pkg-plist' for 'bin/lynx'
> and shot myself in a foot! :P
> Even if it did returned "sane" amount of matches, speed was atrocious.
time find /usr/ports/ -name pkg-plist | xargs grep bin/lynx$
/usr/ports/finance/ledgersmb/pkg-plist:@dirrm led
> If the driver is doing something daft like DELAY(x) in a fast
> interrupt handler which would lead to that behaviour, it should be
> fixed.
>
> If it's doing a DELAY(x) in a critical section, it shuld be fixed.
They are doing *something* that completely locks out everything else.
It is always a
> Which device drivers? We can't fix problems we don't know about.
ata(4) completely hung the system for 19 minutes (at which point
I manually intervened, see the PR), probably an infinite loop.
http://www.freebsd.org/cgi/query-pr.cgi?pr=170675
Siis(4) and ahci(4) have also caused data loss, pr
Domagoj writes:
> MBR supports max of 4 slices/partitions.
4 primary partitions, there are the "extended/logical partitions",
which allow more.
> The '/usr/mdec/mbr_bootsel', which you've mentioned, is equivalent
> to FreeBSD's '/boot/boot0', which is tuned via 'boot0cfg' util.
> It will also sh
[ from the FreeBSD for serious performance? thread ]
> > So I use NetBSD's MBR for disks I want
> > to boot from.
>
> Can I have a CMD sequence?
>
> First would be ...
> # fetch ...
Read NetBSD's fdisk(8) and mbr(8).
The MBR is only 512 bytes, and must contain the code and data.
This is very lim
>>Ronald writes:
>>> the last Alpha to be produced was shipped way back in 2004... eight years
>>> ago... with a top speed of 1.3 GHz I now have a cheap little media player
>>> thingy sitting on my desk, and _each_ of its two cores runs faster than tha\
t.
>>> In short, Alphas hardly constitute hig
[ lack of SATA NCQ support for nforce4-ultra ]
Adrian writes:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=e2e031eb09760c36099ac127eeb175e06d257aef
which is:
The mcp61 has bug with ncq.
- { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA), SWNCQ },
- {
Ronald writes:
> the last Alpha to be produced was shipped way back in 2004... eight years
> ago... with a top speed of 1.3 GHz. I now have a cheap little media player
> thingy sitting on my desk, and _each_ of its two cores runs faster than that.
> In short, Alphas hardly constitute high-end hard
Ronald writes:
> This probably wouldn't be such a big deal if we were just talking about
> Linux. But FreeBSD has always prided itself on being a serious OS for
> serious people with serious work to do... like major server farms and
> such. In the context of high-end applications on high-end hard
Julian writes:
> it is however a good way to get mismatching kernel and userland
> but that's not what we are discussing.
The method recommended on
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-building.html
"# make buildkernel KERNCONF=MYKERNEL"
is also a good way to get
Alan writes:
> In conclusion, I think it's time that we change M_NOWAIT so that it doesn't
> dig any deeper into the cache/free page queues than M_WAITOK does and
> reintroduce a M_USE_RESERVE-like flag that says dig deep into the
> cache/free page queues. The trouble is that we then need to ident
> In the last 72 hours, we've had two different systems freeze; they don't
> apparently recognize any interrupts, they won't respond to ping, and
> they require a powercycle to reboot. We can't easily generate an NMI on
> these boxes.
> Just on the off chance, does this sound like a familiar -- an
Yuri writes:
> Anything else I can try?
>
> One thing of importance here is that there is an older graphics card
> 9400 GT on this system and current nvidia-driver-295.71 has an issue
> with 9400 GT: it makes graphics to malfunction (unpainted windows, long
> delays switching to terminal mode) or
Adrian writes:
> the "cycle over a short period" may not be the driver writing the same
> crap to the card. I've seen similar failure modes in windows where
> during playback, if the system hangs for whatever reason, the card
> plays the last sample over and over in a loop.
Ok, that makes sense.
Yuri writes:
> One of my 9.1-BETA1 systems periodically freezes. If sound was playing,
> it would usually cycle with a very short period. And system stops being
> sensitive to keyboard/mouse. Also ping of this system doesn't get a
> response.
So the sound continues, on and off, while everything el
>>> da0: 3.300MB/s transfers
>>> da0: Command Queueing enabled
>
> root@freebsd:/root # dd if=/dev/zero of=/dev/da1 bs=16384 count=262144
>
> 4294967296 bytes transferred in 615.840721 secs (6974153 bytes/sec)
1) Does a larger block size (bs=1m) help?
2) That's roughly the speed I'd expect withou
>> Why not create a command wtf(1)?
>>
> there are really lot of good features that can be made in FreeBSD.
> actually good, instead of that crap
While this is certainly not the most important improvement that could
be made (Fix the PRs!), the proposed wtf command could be useful.
And, importantly
> As long as it can be toggled off system-wide, persistently (sysctl?), I
> can't see the harm in bringing that in.
It violates the Unix Philosophy.
"Make each program do one thing well. To do a new job, build afresh
rather than complicate old programs by adding new features."
http://www.faqs.or
These schemes to just put the metadata in some special location
and have all the tools know about it create a lot of problems.
There is always some tool that doesn't know. There is always
some human that doesn't know. Telling the difference between
real metadata and some other data that happens to
Robert writes:
> 3) the box is responsive to hitting enter at the console (it produces
> another login: prompt)
Getty is in memory and can run.
> 5) if I try to login to the console, it lets me enter a username then
> locks up totally, it does not present me with
>> Robert writes:
>>> 3) the box is responsive to hitting enter at the console (it produces
>>> another login: prompt)
>>
>> Getty is in memory and can run.
>>
>>> 5) if I try to login to the console, it lets me enter a username then
>>> locks up totally, it does not present me with a password: pro
Robert writes:
> 3) the box is responsive to hitting enter at the console (it produces
> another login: prompt)
Getty is in memory and can run.
> 5) if I try to login to the console, it lets me enter a username then
> locks up totally, it does not present me with a password: prompt.
Login(1) is
Wojciech writes:
> 1) i know for a friend that on some motherboards (it was embedded VIA
> based CPU) geli doesn't work at typing password.
>
> 2) in my case (as well as his case) problems happen everytime kernel
> function cngets is used, it maybe after being unable to mount root in
> a kernel pro
user.vdr writes:
> Tuners do NOT provide raw audio/video to the system in any case.
http://corona.homeunix.net/cx88wiki/Overview/RawVideo
>>>
>>> While that's technically possible in _some_ cases, and assuming it's
>>> fully implemented and functional, I'm unaware of any software that
user.vdr writes:
>> As long as there remain some NTSC broadcasts, there might be some
>> that you wish to watch. That's why I wrote:
>
> Yes, technically there are still some that exist, for now. However,
> their death certificate is signed and they're so few that it's not
> worth mentioning.
If y
user.vdr writes:
>>> Recording doesn't require any compression unless you are transcoding
>>> in real-time. There's no difference between recording ATSC, NTSC, PAL,
>>> etc, and it's actually irrelevant what the stream is.
>>
>> This is incorrect. ATSC is compressed before broadcast, so
>> you rece
> This is a known issue, and had been around for a long time.
> You can't reliably build 32 bit binaries (what the -m32 flag specifies)
> on a 64 bit system. The header files (and possibly other things) are wrong.
People build 32 bit binaries on 64 bit systems all the time.
It is called cross-comp
user.vdr writes:
> Recording doesn't require any compression unless you are transcoding
> in real-time. There's no difference between recording ATSC, NTSC, PAL,
> etc, and it's actually irrelevant what the stream is.
This is incorrect. ATSC is compressed before broadcast, so
you receive the data
[ Added multimedia@ as that is a more appropriate list than hackers ]
> I just moved into a very cramped apartment
> we are using a broadcast signal only [current US {NYC} standards]
You'll need to know if you have any NTSC (analog) stations you
care about or if everything is ATSC (digital). Hop
Spending resources to create more releases is pointless when
the PRs aren't getting fixed. "Oh, Look! Release 9.2.2.2.2.2
is out! The system still crashes every 5 seconds, but a typo
on the true(1) man page is fixed."
We need a more global discussion about all the things that
resources are spen
Brandon writes:
> Booting into Ubuntu minimal or my own custom Linux distro,
> literally takes 0.5-2 seconds to boot up to shell
0.5-2 seconds from power-on to a shell prompt? How do you
get through the firmware that fast, much less firmware plus
an OS?
Which reminds me, back when I was triple-b
1) tar up files
2) encrypt tarball
3) copy encrypted tarball with rcp, ftp, uucp, ...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@free
Robert writes:
> I want this:
>
> # echo test\ttest > test
> # cat test
> test test
I have given up on using echo for anything the least bit fancy,
in favor of printf(1) which gives much better control.
printf "test\ttest\n"
___
freebsd-hackers@freeb
*WHY* is Linux so much more popular than the BSDs?
GPL vs BSDL ? (Create a GPLed BSD and see if it takes off.)
the obese cartoon penguin?
Do most people actually prefer the lower quality product?
Popularity is inversly proportional to quality in many
areas, not just OSes.
marketing?
Is there s
Konstantin Belousov wrote:
> My opinion is that such tool should be imported into the base.
Why?
Don't optional tools belong in ports?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe,
Andrey writes:
> Wired memory: kernel memory and yes, application may get wired memory
> through mlock()/mlockall(), but I haven't seen any real application
> which calls mlock().
Apps with real time considerations may need to lock memory to prevent
having to wait for page/swap.
__
Brandon writes:
> I'm still avidly trying to work on this idea, but right now the issue
> seems to be with AMD and NVIDIA not documenting their protocols. Intel
> does a good job, but I don't have any Intel chips with graphics laying
> around.
I thought that AMD had documented most of it by now, w
> Subsequent inspection suggested that it was happening during the
> periodic daily, though we never managed to get it to happen by manually
> forcing periodic daily, so that's only a theory.
Perhaps due to a bunch of VMs all running periodic daily at the same time?
> We had a perfectly functiona
>> mlock(2) says:
>>
>> > A single process can mlock() the minimum of a system-wide
>> > ``wired pages'' limit and the per-process RLIMIT_MEMLOCK
>> > resource limit.
>>
>> Shouldn't this say maximum rather than minimum?
>
> I don't think so. The minimum of the two would be the limit that you
> wi
> FreeBSD ?? - 7.4 never crash
> FreeBSD 8.0 - 8.2 crashes
Obvious short term workaround is to run production on 7.4 (assuming you can)
until you figure out what is wrong with 8.x.
What filesystem(s) are you running? UFS? ZFS? other?
> started randomly disconnecting people every morning
Due to
mlock(2) says:
> A single process can mlock() the minimum of a system-wide
> ``wired pages'' limit and the per-process RLIMIT_MEMLOCK
> resource limit.
Shouldn't this say maximum rather than minimum?
> [EAGAIN] Locking the indicated range would exceed either the
> system or per-process limit for
amd64
4 GiB
nVidia nForce CK804 (aka nforce4-ultra), SiI3132, JMB363
sata disks
FreeBSD 8.2
FFS/SU
Problem: I/O to one disk can fill up the disk buffer cache,
starving other processes of disk I/O. If the other processes
are logging real time data (from a closed source "black box"),
then data is l
Brandon writes:
> (If you haven't noticed, I'm going to keep finding excuses to
> write this as I really am kindof excited to learn/work on it)
ideas:
Display PostScript
rio (from Plan 9)
If you're mainly looking for a low-level graphics project,
maybe reverse engineer something on the GPU (e.g
>> The problem then is how to feed both machines the same inputs, and
>> compare the outputs. Do we need a third machine to supervise?
>> Can we have each machine keep an eye on the other, avoiding the
>> need for a third machine?
>
> A pair would work as long as the only failures are "obvious" (e.
Rayson writes:
> The question is, are we planning to handle >95% of the errors for >99%
> of the hardware we run on, or are we really planning to spend years
> trying to design something that would require special hardware
> support?
I assume this started as: "Oh look, most CPUs have multiple core
>>> The original goal for 5.0 was to completely remove the Giant lock (and
>>> do other cool SMP-related stuff). Eventually it was realized that this
>>> was too big a goal to fully accomplish in 5.0 (albeit too late in the
>>> process) and the goal was changed to do the basic framework for the new
Igor writes:
> You mean something like: http://people.freebsd.org/~edwin/gnats/ ?
Daniel writes:
> http://www.oook.cz/bsd/prstats/
Yes, something like these.
Stephen writes:
> You should get extra points for difficult PR's. One way to measure this
> would be to give more points for fixing older
Andriy writes:
> And dealing with PRs is not always exciting.
Neither is brushing your teeth or cleaning the kitchen, but most of us
manage to do them at least occasionally. Part of being a grown up.
Instead of looking for a stick to hold over developers to get them
to fix PRs, let's look for car
> The original goal for 5.0 was to completely remove the Giant lock (and
> do other cool SMP-related stuff). Eventually it was realized that this
> was too big a goal to fully accomplish in 5.0 (albeit too late in the
> process) and the goal was changed to do the basic framework for the new
> SMP m
John writes:
> - EOL 7
> - mark 8 as legacy
> - mark 9 as the _only_ production release
> - release 10.0 in January 2017
Until a few days ago 8 was the latest, shinest release.
So you want to suddenly demote it all the way down to legacy?
I thought the goal was to have releases that can be used fo
Atom writes:
> i bought myself a LENOVO T510 when it first came out, around early 2010.
> it's got an i5 CPU and Arrandale GPU. it's two years old and on freeBSD i
> STILL can't run xorg properly with it.
I have a machine from 2005-08 that FreeBSD still doesn't support properly
in 2012. After much
> I have kde4 on 8.2 with translucency windows effect enabled and nvidia
> graphics driver.
> Every time I switch an active window or maximize some window, sound
> played by mplayer interrupts for ~0.5 sec. Very annoying effect. Problem
> disappears when windows effects in kde4 are turned off.
> Is
The system doesn't go multiuser until the rc jobs complete,
even if you attempt to background them with '&'. This can be
a problem with long running jobs. I started using cron @reboot
for this reason.
I haven't run into the problem since I've never needed to run
/etc/rc.d/cron restart.
> Add an
> something like the following inside lseek() would take care of tape drives:
>
> if (S_ISCHR(sb.st_mode) || S_ISBLK(sb.st_mode)) {
> if (ioctl(io->fd, FIODTYPE, &type) == -1)
> err(1, "%s", io->name);
>
> if (type & D_TAPE)
>
> lseek() on a tape drive does not return an error, nor does it
> actually do anything.
IIRC some tape drives can seek, while others cannot.
Vague memories that it is supposed to be possible to put a
filesystem on a DECtape and mount the filesystem.
It might be that FreeBSD doesn't currently supp
>>> The data sheet for intel 82576 advertises IP TX/RX checksum offload
>>> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean
>>> that driver (and chip) do not support IP TX checksum offload or the
>>> support for TX is not yet included in the driver?
>>
>> The first question
> The data sheet for intel 82576 advertises IP TX/RX checksum offload
> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean that
> driver (and chip) do not support IP TX checksum offload or the support for
> TX is not yet included in the driver?
The first question is "is checks
>> Firefox 5 and 6 has more gettimeofday call than 2 per second on my
>> amd64-8.2-stable box.
> i don't see why chromium needs
> to call gettimeofday(2) or any library function that triggers it more
> than 3000 times a second.
What the are web browsers doing that they "need" the clock
so of
>> I guess formatting the filesystem for 4k sectors on a 512b drive would still
>> work but it would be suboptimal. What would the performance penalty be in
>> reality?
>
> It would be suboptimal but only for the slight waste of space that would
> have otherwise been reclaimed if the block or frag
> CONFDIR is for base, not ports
Perhaps ${BASE_CONF_DIR}, ${PORTS_CONF_DIR}, ...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd
>> I've been working on fixing problems with printf(9), log(9) and
>> related functions. Today I tried converting printf(9) to write
>> to the log rather than directly to the console, unless the log is
>> not open, in which case the message is also sent to the console.
>> Printf(...) is now the sam
I've been working on fixing problems with printf(9), log(9) and
related functions. Today I tried converting printf(9) to write
to the log rather than directly to the console, unless the log is
not open, in which case the message is also sent to the console.
Printf(...) is now the same as log(LOG_I
Peter writes:
>> A better approach is to be able to boot whatever slice you
>> want without having to change the active slice.
>>
>> NetBSD can do this. The MBR puts up a menu of the bootable
>> slices on the disk being booted. You can allow the timer
>> to time out and boot the default. Or you ca
>> please keep in mind that -Wfoo does reflect the ideas of the GNU people
>> regarding *proper* code. the warnings themselves are sometimes wrong,
>> because they complain about perfectly correct code.
I attempted to get the gcc people to improve this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
Chris writes:
>> Ports need attention. The warnings I get there are frightening.
>
> I find it comforting that they're just that: warnings.
>
> How do they frighten you?
High quality code does not have any warnings.
The most frightening thing is the attitute that "They're just warnings,
so I'll i
> maybe we find some nice -Wwarning options which are reasonable
> to have
-Wmissing-declarations
-Wimplicit
FreeBSD's gcc doesn't seem to have -Wcoercion ???
Bugzilla indicates that it was added years ago (2006?).
It would be really really nice if -static worked on (nearly) everything.
> and
>> I have i.e; 3 slices, of which first is active.
>> Now I wana set slice 2 active, but only for a one/next boot.
>> Once slice 2 is booted and system is shutdown or rebooted,
>> once again, first slice is active and booted, without user's intervention.
I think that setting the active slice is th
> There's really only room for one or two more menu items.
Perhaps some items could be moved to a 2nd level menu?
1) boot multiuser mode ( default )
2) boot single user mode
3) menu to set boot options
4) help
Would be nice: a fix for having to lean on a key autorepeating
for a couple
> Already on the to-do list is to support ``loader_logo=...'' in
> /boot/loader.conf
Including an option for no logo? (For consoles that are slow and/or
small, and for people that just don't like the logos.)
>> Putting brackets around letters (and numbers) sounds good.
>> If there is room, perhap
[ attempt #2 - grumble - sorry about the blank message, hope it
works this time - grumble- ]
> I hope that works for serial console. VT100 may be a reasonable
> default in that case, but it would be good to make sure that menu
> works even on a dumb terminal. Perhaps we should put 'key' letter
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
> I'm investigating an issue we are seeing with 6.1-RELEASE and the bge
> driver dropping packets sporadically at 100MBps speed.
> Its get mainly aggravated when heavy disk I/O occurs
> Has anyone seen this problem before with bge? Am I barking up the
> wrong tree with my initial investigation?
> You also can't dual boot without console access.
You can, I have a system triple booting without using
the console.
Method 1: boot through grub. Create shell scripts that
edit grub's menu.lst file.
Method 2: use fdisk(8) to change active partition.
With or without dual booting, if the least
> >> Any input on the reliability of SII3512 is also welcomed.
> >
> >dmesg | grep 3512
> >satalink0: Silicon Image SATALink 3512 (rev. 0x01)
> >
> >No reliability problems from the 3512. (up 74 days)
> >
> >This is on an Alpha box running NetBSD. I haven't tried the 3512
> >with FreeBSD.
I took
> pcirev
> { ATA_SII3512, 0x02, SIIMEMIO, 0, ATA_SA150, "SiI 3512" },
> { ATA_SII3512, 0x00, SIIMEMIO, SIIBUG,ATA_SA150, "SiI 3512" },
What happened to rev 1?
> Any input on the reliability of SII3512 is also welcomed.
dmesg | grep 3512
satalink0: Silicon Image S
So who, exactly, is the best person to write to requesting
docs for AMD/ATI graphics/video chips?
We need to politely inform them that
There are a lot of operating systems out there,
and they all need high quality, fully functional drivers.
FreeBSD, NetBSD, OpenBSD, Plan-9
>>> Just wondering if there is any planned support for this card (or similar)
>>
>> I've added sos@ to Cc list, who may have interest to this as well. Note
>> that developing drivers requires that the developer has his hands on
>> actual hardware and hardware specifications.
>
> Exactly, get me th
In message <[EMAIL PROTECTED]>, Remko Lodder writes:
> Synopsis: Need SATA NCQ support
>
> State-Changed-From-To: open->closed
> State-Changed-By: remko
> State-Changed-When: Mon Dec 4 20:29:54 UTC 2006
> State-Changed-Why:
> Hello, this is not a PRoblem but a request for assistance. Please reask
90 matches
Mail list logo
