Re: 13.0: partiton names changed

[Stefan Ehmann]

On Monday, April 12, 2021 9:31:21 AM CEST Andrey V. Elsukov wrote:
> 10.04.2021 16:38, Stefan Ehmann пишет:
> > I've just updated an old machine from 12.2 to 13.0
> > (ea31abc261ffc01b6ff5671bffb15cf910a07f4b)
> > 
> > Attaching the /home EBR partition gave me this puzzling error:
> > 
> > # geli attach ada0s5
> > Enter passphrase:
> > geli: Provider not found: "ada0s5"
> > geli: There was an error with at least one provider.
> > 
> > Further investigation showed that there is a symlink from /dev/ada0s5 to
> > ada0s4+0001 but geom doesn't recognize ada0s5 anymore.
> > 
> > Didn't find anything about it in the release notes:
> > https://www.freebsd.org/releases/13.0R/relnotes/
> > 
> > I guess EBR is no longer in wide use, but this is an old installation, as
> > already mentioned.
> 
> https://reviews.freebsd.org/D24939

Thanks for the pointer (PR 232463 was already mentioned in private 
communications).

As I said above, there is a symlink in /dev. But geom eli is not aware of any 
aliases/links which breaks EBR eli entries in /etc/fstab.

After reading the summary of D24939, I'm not sure if this behavior is 
intentional.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

13.0: partiton names changed

[Stefan Ehmann]

I've just updated an old machine from 12.2 to 13.0
(ea31abc261ffc01b6ff5671bffb15cf910a07f4b)

Attaching the /home EBR partition gave me this puzzling error:

# geli attach ada0s5
Enter passphrase:
geli: Provider not found: "ada0s5"
geli: There was an error with at least one provider.

Further investigation showed that there is a symlink from /dev/ada0s5 to
ada0s4+0001 but geom doesn't recognize ada0s5 anymore.

Didn't find anything about it in the release notes:
https://www.freebsd.org/releases/13.0R/relnotes/

I guess EBR is no longer in wide use, but this is an old installation, as
already mentioned.

gpart list in 12.2:
Geom name: ada0s4
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 473451614
first: 0
entries: 7515105
scheme: EBR
Providers:
1. Name: ada0s5
   Mediasize: 41948895744 (39G)
   ...

13.0:
Geom name: ada0s4
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 473451614
first: 0
entries: 7515105
scheme: EBR
Providers:
1. Name: ada0s4+0001
   Mediasize: 41948895744 (39G)
   ...


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 13.0-BETA1: ipfw regression?

[Stefan Ehmann]

On Tuesday, February 9, 2021 11:23:32 PM CET Stefan Ehmann wrote:
> I'm having issues with stale TCP connections after the upgrade from 12.2 to
> 13.0-BETA1.
>
> Symptoms:
> Outgoing TCP connections no longer receive data after being idle.
>
> I can do more testing later, but I think these ipfw rules trigger the
> problem: - check-state
> - allow tcp from me to any setup keep-state
> - deny ip from any to any

PR created:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253476


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 13.0-BETA1: ipfw regression?

[Stefan Ehmann]

On Thursday, February 11, 2021 7:57:43 AM CET Helge Oldach wrote:
> Hi Stefan,
>
> Stefan Ehmann wrote on Thu, 11 Feb 2021 02:50:35 +0100 (CET):
> > On Wednesday, February 10, 2021 7:46:25 AM CET Helge Oldach wrote:
> > > Hi,
> > >
> > > Stefan Ehmann wrote on Tue, 09 Feb 2021 23:23:32 +0100 (CET):
> > > > I'm having issues with stale TCP connections after the upgrade from
> > > > 12.2
> > > > to
> > > > 13.0-BETA1.
> > > >
> > > > Symptoms:
> > > > Outgoing TCP connections no longer receive data after being idle.
> > > >
> > > > I can do more testing later, but I think these ipfw rules trigger the
> > > > problem: - check-state
> > > > - allow tcp from me to any setup keep-state
> > > > - deny ip from any to any
> > > >
> > > > After establishing an outgoing connection (e.g, via netcat), I see a
> > > > new
> > > > dynamic rule and the 300s counter running down via
> > > > # ipfw -Da list
> > > >
> > > > net.inet.ip.fw.dyn_keepalive is set to 1, so the timer should be
> > > > refreshed
> > > > via keep-alive on idle connections.
> > > >
> > > > Don't know if it's deterministic, but from what I've seen so far:
> > > > - When counter gets low the first time, it is reset to 300 as
> > > > expected.
> > > > - When the counter nears zero for the second time, the dynamic rule is
> > > > deleted and I get ipfw denies.
> > >
> > > I am afraid I can't reproduce. I have followed your test case however
> > > I'm seeing that a TCP keepalive reliably triggers a timer refresh. For
> >
> > > example (sleep 1 loop over ipfw -Da list | grep):
> > Tested in VirtualBox with amd64.vmdk from:
> >
> > https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-BETA1/
>
> We do agree on amd64, right?
>
> I precisely followed your steps (VirtualBox 6.1.18), except:
[...]

For some reason, the issue only occurs with bridged network, not NAT network
(virtualbox-ose-5.2.44_4)
>
> I am seeing keepalives every 5 minutes and the ipfw timer has fired
> every time, resetting the dynamic rule to 300 secs TTL. I am also seeing
> keepalives received and replied in the tcpdump. Everything according
> to the books I am afraid. My nc session is still sending after some 45
> minutes.
>
> > Updated to 187492ef639f, but nothing changed.
>
> Hmmm. I'm out of ideas. Are you 100% sure the remote session is not torn
> down routinely after something between 300-600 seconds silence?

Finally did a git bisect:
283c76c7c3f2f634f19f303a771a3f81fe890cab is the first bad commit

There is PR 252449 where sysctl net.inet.tcp.tolerate_missing_ts was
introduced.

tolerate_missing_ts should only be necessary for communicating with broken TCP
stacks, as far as I understand. I think there's another problem because I'm
also seeing this issue using epair devices.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 13.0-BETA1: ipfw regression?

[Stefan Ehmann]

On Thursday, February 11, 2021 7:57:43 AM CET Helge Oldach wrote:
> Hi Stefan,
>
> Stefan Ehmann wrote on Thu, 11 Feb 2021 02:50:35 +0100 (CET):
> > On Wednesday, February 10, 2021 7:46:25 AM CET Helge Oldach wrote:
> > > Hi,
> > >
> > > Stefan Ehmann wrote on Tue, 09 Feb 2021 23:23:32 +0100 (CET):
> > > > I'm having issues with stale TCP connections after the upgrade from
> > > > 12.2
> > > > to
> > > > 13.0-BETA1.
> > > >
> > > > Symptoms:
> > > > Outgoing TCP connections no longer receive data after being idle.
> > > >
> > > > I can do more testing later, but I think these ipfw rules trigger the
> > > > problem: - check-state
> > > > - allow tcp from me to any setup keep-state
> > > > - deny ip from any to any
> > > >
> > > > After establishing an outgoing connection (e.g, via netcat), I see a
> > > > new
> > > > dynamic rule and the 300s counter running down via
> > > > # ipfw -Da list
> > > >
> > > > net.inet.ip.fw.dyn_keepalive is set to 1, so the timer should be
> > > > refreshed
> > > > via keep-alive on idle connections.
> > > >
> > > > Don't know if it's deterministic, but from what I've seen so far:
> > > > - When counter gets low the first time, it is reset to 300 as
> > > > expected.
> > > > - When the counter nears zero for the second time, the dynamic rule is
> > > > deleted and I get ipfw denies.
> > >
> > > I am afraid I can't reproduce. I have followed your test case however
> > > I'm seeing that a TCP keepalive reliably triggers a timer refresh. For
> >
> > > example (sleep 1 loop over ipfw -Da list | grep):
> > Tested in VirtualBox with amd64.vmdk from:
> >
> > https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-BETA1/
>
> We do agree on amd64, right?

Yes, amd64.

> I precisely followed your steps (VirtualBox 6.1.18), except:
> > Terminal 1:
> > kldload ipfw
> > ipfw add check-state
> > ipfw allow tcp from me to any setup keep-state
>
> ipfw add allow tcp from me to any setup keep-state
>
> > /bin/sh (I don't speek csh)
>
> toor is my friend :-)
>
> > while true; do sleep 1; ipfw -Da list; done
>
> while sleep 1; do ipfw -Da list; done
>
> > Terminal 2:
> > nc  12345
>
> nc  80
>
> (Apache is listening on .)
>
> > On  nc -l 12345 is running
>
> On : tcpdump port 80
>
> I am seeing keepalives every 5 minutes and the ipfw timer has fired
> every time, resetting the dynamic rule to 300 secs TTL. I am also seeing
> keepalives received and replied in the tcpdump. Everything according
> to the books I am afraid. My nc session is still sending after some 45
> minutes.
>
> > Updated to 187492ef639f, but nothing changed.
>
> Hmmm. I'm out of ideas. Are you 100% sure the remote session is not torn
> down routinely after something between 300-600 seconds silence?

Yes. If I remove the deny rule, the connection is still working after the
dynamic rule expired.

Thanks so far. I'll try some more testing on different hardware over the
weekend.

Initially, I've seen the problem on epair(4) devices. That should rule out
network hardware issues.

I've never seen this problem on 12.2 but I hope I can avoid a git bisect from
there.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 13.0-BETA1: ipfw regression?

[Stefan Ehmann]

On Wednesday, February 10, 2021 7:46:25 AM CET Helge Oldach wrote:
> Hi,
>
> Stefan Ehmann wrote on Tue, 09 Feb 2021 23:23:32 +0100 (CET):
> > I'm having issues with stale TCP connections after the upgrade from 12.2
> > to
> > 13.0-BETA1.
> >
> > Symptoms:
> > Outgoing TCP connections no longer receive data after being idle.
> >
> > I can do more testing later, but I think these ipfw rules trigger the
> > problem: - check-state
> > - allow tcp from me to any setup keep-state
> > - deny ip from any to any
> >
> > After establishing an outgoing connection (e.g, via netcat), I see a new
> > dynamic rule and the 300s counter running down via
> > # ipfw -Da list
> >
> > net.inet.ip.fw.dyn_keepalive is set to 1, so the timer should be refreshed
> > via keep-alive on idle connections.
> >
> > Don't know if it's deterministic, but from what I've seen so far:
> > - When counter gets low the first time, it is reset to 300 as expected.
> > - When the counter nears zero for the second time, the dynamic rule is
> > deleted and I get ipfw denies.
>
> I am afraid I can't reproduce. I have followed your test case however
> I'm seeing that a TCP keepalive reliably triggers a timer refresh. For
> example (sleep 1 loop over ipfw -Da list | grep):

Tested in VirtualBox with amd64.vmdk from:

https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-BETA1/

Terminal 1:
kldload ipfw
ipfw add check-state
ipfw allow tcp from me to any setup keep-state

/bin/sh (I don't speek csh)
while true; do sleep 1; ipfw -Da list; done

Terminal 2:
nc  12345

On  nc -l 12345 is running

Updated to 187492ef639f, but nothing changed.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 13.0-BETA1: ipfw regression?

[Stefan Ehmann]

On Wednesday, February 10, 2021 7:46:25 AM CET Helge Oldach wrote:
> Hi,
>
> Stefan Ehmann wrote on Tue, 09 Feb 2021 23:23:32 +0100 (CET):
> > I'm having issues with stale TCP connections after the upgrade from 12.2
> > to
> > 13.0-BETA1.
> >
> > Symptoms:
> > Outgoing TCP connections no longer receive data after being idle.
> >
> > I can do more testing later, but I think these ipfw rules trigger the
> > problem: - check-state
> > - allow tcp from me to any setup keep-state
> > - deny ip from any to any
> >
> > After establishing an outgoing connection (e.g, via netcat), I see a new
> > dynamic rule and the 300s counter running down via
> > # ipfw -Da list
> >
> > net.inet.ip.fw.dyn_keepalive is set to 1, so the timer should be refreshed
> > via keep-alive on idle connections.
> >
> > Don't know if it's deterministic, but from what I've seen so far:
> > - When counter gets low the first time, it is reset to 300 as expected.
> > - When the counter nears zero for the second time, the dynamic rule is
> > deleted and I get ipfw denies.
>
> I am afraid I can't reproduce. I have followed your test case however
> I'm seeing that a TCP keepalive reliably triggers a timer refresh. For
> example (sleep 1 loop over ipfw -Da list | grep):
>
[...]

Repeated my tests with tcpdump on remote host.

What I see: First the timer goes down to ~20s and is reset to 300s (as
expected). The remote host sees a keep-alive-packet at that point.

On second run, there's no keep-alive packet seen on the remote host.
Timer expires and rule is removed. Expected at this point since there was no
keep-alive exchange.

The connection is still working at this point (deny rule was deleted).

> This is amd64 stable/13-n244495-7d9e00cd8bd which is slightly more
> recent than BETA1 I believe. Can you share the git commit please

I'm on releng/13.0 (just updated to 0b54d2764737).

There are some additional commits in stable/13 (including sys/net). I can try
stable later.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

13.0-BETA1: ipfw regression?

[Stefan Ehmann]

I'm having issues with stale TCP connections after the upgrade from 12.2 to
13.0-BETA1.

Symptoms:
Outgoing TCP connections no longer receive data after being idle.

I can do more testing later, but I think these ipfw rules trigger the problem:
- check-state
- allow tcp from me to any setup keep-state
- deny ip from any to any

After establishing an outgoing connection (e.g, via netcat), I see a new
dynamic rule and the 300s counter running down via
# ipfw -Da list

net.inet.ip.fw.dyn_keepalive is set to 1, so the timer should be refreshed via
keep-alive on idle connections.

Don't know if it's deterministic, but from what I've seen so far:
- When counter gets low the first time, it is reset to 300 as expected.
- When the counter nears zero for the second time, the dynamic rule is deleted
and I get ipfw denies.




___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: HOWTO donate CPU to the fight against the Corona-virus

[Stefan Ehmann]

On Sunday, March 22, 2020 11:38:31 AM CEST Stefan Ehmann wrote:
> On Saturday, March 21, 2020 12:07:55 PM CET Alexander Leidinger wrote:
> > Quoting Stefan Ehmann  (from Sat, 21 Mar 2020
> >
> > 11:38:26 +0100):
> > > On Thursday, March 19, 2020 8:57:45 AM CET Alexander Leidinger via
> > > freebsd-
> > >
> > > stable wrote:
> > >> Hi,
> > >>
> > >> if someone wants to donate some FreeBSD based CPU resources to the
> > >> fight against the Corona-virus, here is a quick HOWTO in terms of
> > >> installing the Folding@Home client on FreeBSD:
> > >>
> > >> https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with
> > >> -f
> > >> ree bsd-foldinghome/
> > >
> > > Unfortunately, (using a CPU slot for the same work unit) TPF is 2-3
> > > times
> > > slower than on Ubuntu for me. Much of the speed difference seems to
> > > be related
> > > to libOpenCL. If remove libOpenCL on Ubuntu, it's still 20-30% faster
> > > than
> > > on FreeBSD.
> >
> > The pure CPU based code should be the same. Someone would have to
> > trace / reverse engineer what is going on.
>
> I'm pretty sure now that libOpenCL is only relevant for GPU slots.
>
> I couldn't reproduce that the presence of libOpenCL.so has any effect on CPU
> slots. Didn't make much sense anyway, something else must have been going
> on. So there's probably no point in getting OpenCL to run on FreeBSD until
> we have GPU rendering.
>
> The numbers displayed by FAHControl are rather strange:
> * There is no discernible difference in speed if 1 or all CPU cores are used
> (but top shows that 600% CPU cycles are burned) - happens on both Ubuntu
> and Linuxolator
> * According to the progress bar, Ubuntu completes 1% per minute, but
> Linuxolator only 0.1% (for the same work unit)
>
> Don't know if the numbers displayed are bogus or there is really that much
> of a difference. Maybe the issue is only related to a specific WU or to
> AMD-CPUs.

Just a short update:
I've tested the port with a different WU and everything seems normal. Speed is
comparable to Linux and multi-core also works as expected.

My previous problems can probably be ignored, not sure what the problem
actually was.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: HOWTO donate CPU to the fight against the Corona-virus

[Stefan Ehmann]

On Saturday, March 21, 2020 12:07:55 PM CET Alexander Leidinger wrote:
> Quoting Stefan Ehmann  (from Sat, 21 Mar 2020
>
> 11:38:26 +0100):
> > On Thursday, March 19, 2020 8:57:45 AM CET Alexander Leidinger via
> > freebsd-
> >
> > stable wrote:
> >> Hi,
> >>
> >> if someone wants to donate some FreeBSD based CPU resources to the
> >> fight against the Corona-virus, here is a quick HOWTO in terms of
> >> installing the Folding@Home client on FreeBSD:
> >>
> >> https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-f
> >> ree bsd-foldinghome/
> >
> > Unfortunately, (using a CPU slot for the same work unit) TPF is 2-3 times
> > slower than on Ubuntu for me. Much of the speed difference seems to
> > be related
> > to libOpenCL. If remove libOpenCL on Ubuntu, it's still 20-30% faster than
> > on FreeBSD.
>
> The pure CPU based code should be the same. Someone would have to
> trace / reverse engineer what is going on.

I'm pretty sure now that libOpenCL is only relevant for GPU slots.

I couldn't reproduce that the presence of libOpenCL.so has any effect on CPU
slots. Didn't make much sense anyway, something else must have been going on.
So there's probably no point in getting OpenCL to run on FreeBSD until we have
GPU rendering.

The numbers displayed by FAHControl are rather strange:
* There is no discernible difference in speed if 1 or all CPU cores are used
(but top shows that 600% CPU cycles are burned) - happens on both Ubuntu and
Linuxolator
* According to the progress bar, Ubuntu completes 1% per minute, but
Linuxolator only 0.1% (for the same work unit)

Don't know if the numbers displayed are bogus or there is really that much of
a difference. Maybe the issue is only related to a specific WU or to AMD-CPUs.

I've also tried https://fahbench.github.io/ but it's mainly targeted at GPUs
and uses a different Core.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: HOWTO donate CPU to the fight against the Corona-virus

[Stefan Ehmann]

On Thursday, March 19, 2020 8:57:45 AM CET Alexander Leidinger via freebsd-
stable wrote:
> Hi,
>
> if someone wants to donate some FreeBSD based CPU resources to the
> fight against the Corona-virus, here is a quick HOWTO in terms of
> installing the Folding@Home client on FreeBSD:
>
> https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-free
> bsd-foldinghome/
>

Unfortunately, (using a CPU slot for the same work unit) TPF is 2-3 times
slower than on Ubuntu for me. Much of the speed difference seems to be related
to libOpenCL. If remove libOpenCL on Ubuntu, it's still 20-30% faster than on
FreeBSD.

Don't know how stable the TPF numbers are, so numbers may be bogus.

Will a CPU slot also use the GPU with libOpenCL or is it just using better
optimized code? I tried to install libOpenCL but all I get is:
OpenCL: Not detected: clGetPlatformIDs() returned -1001

Since there's no CUDA support for FreeBSD, I guess there is no point in trying
getting GPU slots to work.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bsdtar: xz threads support disabled

[Stefan Ehmann]

On 11/24/18 9:47 AM, Stefan Ehmann wrote:
> Is there any reason why bsdtar is built without XZ multi-threading support?
> 
> It's not documented in the man page, so maybe it's an experimental feature.
> 
> Can be tested with this command:
> tar -Jcf /dev/null --options xz:threads=4 $HOME
> 
> After setting HAVE_LZMA_STREAM_ENCODER_MT, it works as expected:

PR created:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233543
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

bsdtar: xz threads support disabled

[Stefan Ehmann]

Is there any reason why bsdtar is built without XZ multi-threading support?

It's not documented in the man page, so maybe it's an experimental feature.

Can be tested with this command:
tar -Jcf /dev/null --options xz:threads=4 $HOME

After setting HAVE_LZMA_STREAM_ENCODER_MT, it works as expected:

Index: lib/libarchive/Makefile
===
--- lib/libarchive/Makefile (revision 340812)
+++ lib/libarchive/Makefile (working copy)
@@ -7,7 +7,7 @@
 LIB=   archive

 LIBADD=z bz2 lzma bsdxml
-CFLAGS+= -DHAVE_BZLIB_H=1 -DHAVE_LIBLZMA=1 -DHAVE_LZMA_H=1
+CFLAGS+= -DHAVE_BZLIB_H=1 -DHAVE_LIBLZMA=1 -DHAVE_LZMA_H=1
-DHAVE_LZMA_STREAM_ENCODER_MT=1

 # FreeBSD SHLIB_MAJOR value is managed as part of the FreeBSD system.
 # It has no real relation to the libarchive version number.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Good motherboard for Ryzen (first-gen)

[Stefan Ehmann]

On 9/22/18 4:53 AM, Eric van Gyzen wrote:
I would like to build a Ryzen desktop.  Can anyone recommend a good 
motherboard?


I'm planning on a first-gen, because the second-gen has similar 
stability problems as the first-gen had, and AMD hasn't released errata 
for the second-gen yet (as far as I know...I would love to be wrong).


I would like to be a cool kid with a Threadripper, but I can't justify 
the cost, so I'm thinking maybe a Ryzen 7 with /only/ 8 cores.  :)


Running Ryzen 7 2700 with Asus X470-PRO. No major problems so far.

Minor issues:
- powerd/amdtemp don't work correctly, I'll probably retest when 12-BETA 
is out

- Linuxolator doesn't work (as petefrench pointed out)
- Had a crash while backing up to external HDD but pretty sure the 
problem was a bad SATA connection


The system does a lot of poudriere builds. Cannot comment on long-time 
stability, system is off at night.



Ideally, I want an Intel NIC, ECC memory support, and a 3-year warranty.


Board has an Intel igb NIC. According to the vendor "ECC support varies 
by CPU". But only found reports of ECC not working, not a single success 
story.


The X370 board is a bit cheaper. Went for X470 because X370 boards may 
require firmware update for 2nd gen Ryzen.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 11.1-RC2 breaks wine, creates unkillable process

[Stefan Ehmann]

On 09.07.2017 14:23, Konstantin Belousov wrote:

On Sun, Jul 09, 2017 at 01:53:24PM +0200, Jan Kokem??ller wrote:

Same here on -CURRENT r320620. r319481 (I think) was working fine.

I'm using the i386-wine-devel package from the official repository.


This should fix creation of the unkillable processes, but untested.

After that, if wine still does not work, you need to look exactly
what breaks, perhaps using ktrace.  Most likely there would be some
unsuccessfull mmap(2) syscall.


The patch fixes the issue. No problems so far, but only tested simple 
applications.


Thank you for the quick fix.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

11.1-RC2 breaks wine, creates unkillable process

[Stefan Ehmann]

After upgrade from stable (r319967) to RC-2 (r320783) wine stops working.

The process gets stuck before there is any console output. It uses 100% 
CPU and is not killable.


I'd guess the stack guard changes broke wine, but I haven't done any 
investigation yet.


The wine package was built by poudriere on 11.0.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: unexpected grep -o behavior

[Stefan Ehmann]

On 21.01.2017 07:28, Kyle Evans wrote:

On Sun, Nov 27, 2016 at 2:52 PM, Stefan Ehmann <shoes...@gmx.net> wrote:

Bug 195763 looks related, but I'm not sure it's the same issue.


Hi,

FYI- that bug is only tangentially related, but I've updated my patch
to also address it while I'm in the neighborhood of where this problem
was.  See Comment #5 if you're interested in a more detailed
explanation.


Thanks a lot for taking care of this bug.
bsdgrep now works for my testcase.

As a side note:
On 11.0-RELEASE (GNU) grep in base suffers the same bug. I tried version 
2.20 on Debian which works correctly. But I assume it won't get updated 
due to GPLv3.


Makes me wonder if we still need two grep variants in base.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

unexpected grep -o behavior

[Stefan Ehmann]

When I try to match the first character of a line grep also matches all
subsequent characters:

$ echo 123 | grep -o '^.'
1
2
3

Same with bsdgrep.
grep from ports works as expected:

$ echo 123 | /usr/local/bin/grep -o '^.'
1

Tested on 11.0.

Bug 195763 looks related, but I'm not sure it's the same issue.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Uppercase RE matching problems in FreeBSD 11

[Stefan Ehmann]

On 07.11.2016 22:13, Charles Swiger wrote:
> On Nov 6, 2016, at 1:49 PM, Stefan Bethke  wrote:
>> Am 06.11.2016 um 22:27 schrieb Baptiste Daroussin
>> :
>>> That works for POSIX locale aka C aka ASCII only world
>> 
>> So what do I set my LANG and LC variables to?  I do want UTF-8, but
>> I do also want my scripts to continue to work.  Clearly,
>> en_US.UTF-8 is not what I want.  Is it C.UTF-8?  Or do I set
>> LANG=en_US.UTF-8 and LC_COLLATE=C?
> 
> If you want to use a UTF8 locale, then you must start using character
> classes like '[:upper:]' and '[:lower:]' because those will-- or at
> least "should", modulo bugs-- properly handle the collation issues
> including for languages which do not possess a 1-1 mapping between
> upper and lower case letters.
> 
> Someone with a German email address is presumably familiar with ß /
> Eszett...?  :-)

Character classes work fine for [a-z], but I don't know of a simple way
to match a range like [a-k].

Personally, I prefer the "Rational Range Interpretation" because it
doesn't break backward compatibility and is still standard compliant.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Uppercase RE matching problems in FreeBSD 11

[Stefan Ehmann]

On 06.11.2016 21:57, Stefan Bethke wrote:
> 
>> Am 06.11.2016 um 12:07 schrieb Baptiste Daroussin
>> :
>> 
>> On Sat, Nov 05, 2016 at 08:23:25PM -0500, Greg Rivers wrote:
>>> I happened to run an old script today that uses sed(1) to extract
>>> the system boot time from the kern.boottime sysctl MIB. On 11.0
>>> this no longer works as expected:
..
>>> Here sed thinks every lowercase character except for 'a' is
>>> uppercase! This differs from the first test where sed did not
>>> think 'o' is uppercase. Again, the above behaves as expected with
>>> LANG=C.
>>> 
>>> Does anyone have any insight into this? This is likely to break a
>>> lot of existing code.
>>> 
>> 
>> Yes A-Z only means uppercase in an ASCII only world in a unicode
>> world it means AaBb... Z because there are way more characters that
>> simple A-Z. In FreeBSD 11 we have a unicode collation instead of
>> falling back in on LC_COLLATE=C which means ascii only
>> 
>> For regrexp for example one should use the classes: :upper: or
>> :lower:.
> 
> That is rather surprising.  Is there a normative reference for the
> treatment of bracket expressions and character classes when using
> locales other than C and/or encodings like UTF-8?

I found an interesting article about this issue in gawk:
https://www.gnu.org/software/gawk/manual/html_node/Ranges-and-Locales.html

Apparently the meaning of ranges is unspecified outside the "C" locale.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03_05
says:

"In the POSIX locale, a range expression represents the set of collating
elements that fall between two elements in the collation sequence,
inclusive. In other locales, a range expression has unspecified
behavior: strictly conforming applications shall not rely on whether the
range expression is valid, or on the set of collating elements matched"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

CPU utilization calculation broken with SCHED_ULE and dummynet

[Stefan Ehmann]

Already posted this earlier this month and filed as kern/128177.

Short summary: top/ps displays 0% instead of 100% CPU usage for CPU-intensive 
processes. single-threaded process on single-CPU i386 machine.

I think this also negatively effects scheduling decisions but haven't found a 
good way to test this.


I did some more investigations today:

The problem only occurs when the dummynet module is loaded. If I unload the 
module everything seems fine. It's enough if the module is loaded, no rules 
involving dummynet are needed.

If I revert 1.214.2.7 (SVN rev 183294) the problem is gone.

Already noted earlier:
I don't see the problem in CURRENT on the same machine. This might be due to 
different configurations though.

If I run the process with idletime priority, I don't see the problem either.

SCHED_4BSD is not affected.


Hope these findings help fixing the problem.

Thanks,
Stefan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: top/ps CPU percentage broken on 7.1-PRERELEASE? (works with SCHED_4BSD)

[Stefan Ehmann]

On Friday 03 October 2008 11:39:37 Jonathan Chen wrote:
 On Fri, Oct 03, 2008 at 10:03:13AM +0200, Stefan Ehmann wrote:
  The CPU % displayed by top/ps for single processes seem to be broken
  here.
 
  E.g. for a simple shell loop:
  top starts displaying around 20% for bash. Within some seconds it
  converges to 0%.
 
  ps values seem to be consistent with top.
 
  The value in the time column seems to be correct. On every refresh it
  increases by 2s.
 
  last pid: 19353;  load averages:  0.99,  0.90,  0.76  up 0+00:37:29
  09:07:00
  119 processes: 2 running, 114 sleeping, 1 stopped, 2 zombie
  CPU: 98.5% user,  0.0% nice,  1.1% system,  0.4% interrupt,  0.0% idle
  Mem: 376M Active, 407M Inact, 144M Wired, 47M Cache, 110M Buf, 13M Free
  Swap: 1280M Total, 1280M Free
 
PID USERNAMETHR PRI NICE   SIZERES STATETIME   WCPU COMMAND
  19352 stefan1  990  4432K  2080K RUN  0:03 15.48% bash
 
  All other process are using 0% CPU.
 
  I did a buildworld/kernel yesterday to be sure everything is in sync. I
  have CURRENT on a different hard disk. Haven't seen the problem there.
  Are there any relevant fixes that weren't MFCed?
 
  Does anyone else see this? This is a single CPU i386 machine.

 Yes, my Java processes now run at 800% at times on my dual processor
 AMD64 system.

I've seen this behaviour too some time ago. Don't know if it's related to what 
I see.

I recompiled my kernel with SCHED_4BSD and things work fine. So it seems to be 
a SCHED_ULE issue.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

top/ps CPU percentage broken on 7.1-PRERELEASE?

[Stefan Ehmann]

The CPU % displayed by top/ps for single processes seem to be broken here.

E.g. for a simple shell loop:
top starts displaying around 20% for bash. Within some seconds it converges to 
0%.

ps values seem to be consistent with top.

The value in the time column seems to be correct. On every refresh it 
increases by 2s.

last pid: 19353;  load averages:  0.99,  0.90,  0.76  up 0+00:37:29
09:07:00
119 processes: 2 running, 114 sleeping, 1 stopped, 2 zombie
CPU: 98.5% user,  0.0% nice,  1.1% system,  0.4% interrupt,  0.0% idle
Mem: 376M Active, 407M Inact, 144M Wired, 47M Cache, 110M Buf, 13M Free
Swap: 1280M Total, 1280M Free

  PID USERNAMETHR PRI NICE   SIZERES STATETIME   WCPU COMMAND
19352 stefan1  990  4432K  2080K RUN  0:03 15.48% bash

All other process are using 0% CPU.

I did a buildworld/kernel yesterday to be sure everything is in sync. I have  
CURRENT on a different hard disk. Haven't seen the problem there.
Are there any relevant fixes that weren't MFCed?

Does anyone else see this? This is a single CPU i386 machine.

-- 
Stefan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

ipfw uid regression

[Stefan Ehmann]

I've updated from 7.0 to RELENG_7 today.

ipfw uid rules have caused problems in the past with PREEMPTION enabled. 
This was fixed in 7.0, at least for me.

In RELENG_7 the old problems are back: Total freeze within some 
seconds/minutes after the first network access.

With WITNESS I get a LOR, see at the end of dmesg.

Copyright (c) 1992-2008 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-PRERELEASE #58: Sat Sep 13 19:38:47 CEST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/TAXMAN
WARNING: WITNESS option enabled, expect reduced performance.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: AMD Athlon(TM) XP 2700+ (2166.44-MHz 686-class CPU)
  Origin = AuthenticAMD  Id = 0x681  Stepping = 1
  
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
  AMD Features=0xc0400800SYSCALL,MMX+,3DNow!+,3DNow!
real memory  = 1073725440 (1023 MB)
avail memory = 1032847360 (985 MB)
ACPI APIC Table: ASUS   A7V8X-X 
ioapic0: Changing APIC ID to 2
ioapic0 Version 0.3 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: ASUS A7V8X-X on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 3ff0 (3) failed
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 32-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
pci1: ACPI PCI bus on pcib1
vgapci0: VGA-compatible display mem 
0xd700-0xd7ff,0xe000-0xefff,0xd600-0xd6ff irq 16 at 
device 0.0 
on pci1
nvidia0: GeForce 6200 on vgapci0
vgapci0: child nvidia0 requested pci_enable_busmaster
vgapci0: child nvidia0 requested pci_enable_io
nvidia0: [GIANT-LOCKED]
nvidia0: [ITHREAD]
pcm0: Envy24 audio (M Audio Audiophile 2496) port 
0xd800-0xd81f,0xd400-0xd40f,0xd000-0xd00f,0xb800-0xb83f irq 16 at device 13.0 
on pci0
pcm0: [ITHREAD]
pcm0: system configuration
  SubVendorID: 0x1412, SubDeviceID: 0xd634
  XIN2 Clock Source: 22.5792MHz(44.1kHz*512)
  MPU-401 UART(s) #: 1
  AC'97 codec: not exist
  ADC #: 1
  DAC #: 1
  Multi-track converter type: I2S(96KHz support, 24bit resolution, ID#0x2)
  S/PDIF(IN/OUT): 1/1 ID# 0x00
  GPIO(mask/dir/state): 0x04/0xfb/0xfe
pci0: multimedia, video at device 15.0 (no driver attached)
uhci0: VIA 83C572 USB controller port 0xb400-0xb41f at device 16.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: VIA 83C572 USB controller on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1: VIA 83C572 USB controller port 0xb000-0xb01f at device 16.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: VIA 83C572 USB controller on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2: VIA 83C572 USB controller port 0xa800-0xa81f at device 16.2 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: VIA 83C572 USB controller on uhci2
usb2: USB revision 1.0
uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb2
uhub2: 2 ports with 2 removable, self powered
ehci0: VIA VT6202 USB 2.0 controller mem 0xd580-0xd58000ff at device 16.3 
on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb3: EHCI version 1.0
usb3: companion controllers, 2 ports each: usb0 usb1 usb2
usb3: VIA VT6202 USB 2.0 controller on ehci0
usb3: USB revision 2.0
uhub3: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb3
uhub3: 6 ports with 6 removable, self powered
isab0: PCI-ISA bridge at device 17.0 on pci0
isa0: ISA bus on isab0
atapci0: VIA 8235 UDMA133 controller port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xa400-0xa40f at device 17.1 on pci0
ata0: ATA channel 0 on atapci0
ata0: [ITHREAD]
ata1: ATA channel 1 on atapci0
ata1: [ITHREAD]
vr0: VIA VT6102 Rhine II 10/100BaseTX port 0xa000-0xa0ff mem 
0xd500-0xd5ff at device 18.0 on pci0
vr0: Quirks: 0x0
vr0: Revision: 0x74
miibus0: MII bus on vr0
rlphy0: RTL8201L 10/100 media interface PHY 1 on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
vr0: Ethernet address: 00:0e:a6:40:3f:d0
vr0: [ITHREAD]
cpu0: ACPI CPU on acpi0
acpi_button0: Power Button on acpi0
fdc0: floppy drive controller port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FILTER]
sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio0: [FILTER]
atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0
atkbd0: AT Keyboard irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
pmtimer0 on isa0
orm0: ISA Option ROM at iomem 0xd-0xd5fff pnpid ORM on isa0
sc0: System console at flags 0x100 on isa0

Re: Possible memory leak?

[Stefan Ehmann]

On Tuesday 20 March 2007 10:44:07 Oliver Fromme wrote:
 Stefan Ehmann wrote:
   Sometimes I'm noticing very high memory usage. Nearly my whole memory
   (1GB) is used although I'm running my usual set of processes - normally
   memory usage is much lower.

 That's normal.  FreeBSD uses nearly all free memory for
 buffer cache and other kinds of caches.

   I killed most processes but memory usage remains high.

 How do you measure memory usage?  The numbers from top(1)
 are mostly meaningless.  Personally I think top should be
 removed from FreeBSD, because it confuses many people (in
 fact I think _most_ people don't interpret the numbers
 correctly), but some people seem to be in love with it. :-)
Obviously I'm one of those people that got it wrong.

My mistake was to think that a memory page is moved to the inactive/cache list 
automatically if it's not used for a longer time. But if I got it correctly 
now, this only happens when there's some kind of memory shortage and the 
pageout daemon is not sleeping.

Now that I think I understand it better, those numbers also seem okay to 
me. :)

What got me suspicious at first was that the systems sometimes started to swap 
although there should have been more than enough memory to fit all processes 
in physical memory. But I see this is also in the FAQ.

Thanks for all your help and hints.

Stefan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Possible memory leak?

[Stefan Ehmann]

Sometimes I'm noticing very high memory usage. Nearly my whole memory (1GB) is 
used although I'm running my usual set of processes - normally memory usage 
is much lower.

I killed most processes but memory usage remains high.

Summing the VSZ values of the ps aux output gives about 34MB. top reports 
316MB active memory.

Where did my memory go? Are there any tools for debugging this?

I don't know what's causing this. I'm using the snd_envy24 driver from 
current, but I think I've seen the problem also when not using sound.

dmesg/ps/top output can be found here:
http://stud4.tuwien.ac.at/~e0125637/fbsd/

If needed, I can provide more details.

Stefan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Possible memory leak?

[Stefan Ehmann]

On Sunday 18 March 2007 20:25:19 Kris Kennaway wrote:
 On Sun, Mar 18, 2007 at 04:19:52PM +0100, Stefan Ehmann wrote:
  Sometimes I'm noticing very high memory usage. Nearly my whole memory
  (1GB) is used although I'm running my usual set of processes - normally
  memory usage is much lower.
 
  I killed most processes but memory usage remains high.
 
  Summing the VSZ values of the ps aux output gives about 34MB. top reports
  316MB active memory.
 
  Where did my memory go? Are there any tools for debugging this?

 This is a FAQ.  free memory is wasted memory.

Sorry for the noise. I somehow thought that's only true for inactive/cache 
memory and active is different - but obviously I was wrong.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

USB (sane) stability issues

[Stefan Ehmann]

I recently acquired a CanoScan LiDE 60.

It basically works but it is very unstable: It often stops during the
scan and sane returns an error, or it just hangs during the scan (making
ugly noises). The only remedy is to re-plug the usb cable. (which
sometimes causes a panic)

I tried on my notebook which is running a recent current. It works
flawlessly there - not a single error so far.

So I upgraded my main computer to 6.1-PRERELEASE but the problem
persists:

- Are there any usb/ehci fixes in CURRENT that haven't made it to
6-stable yet? (I really don't want to update the machine that's making
troubles to current)

- Or is this more likely to be chipset related (the notebook dmesg shows
Intel 82801DB/L/M (ICH4) USB 2.0 controller vs VIA on the computer
that causes troubles)

Also, it occured to me that this could be power related - the scanner
doesn't require an external power suppply. I tried different USB ports
but didn't notice any difference.

dmesg can be found here:

TIA,
Stefan

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: USB (sane) stability issues

[Stefan Ehmann]

On Thu, 2006-04-06 at 16:53 +0200, Stefan Ehmann wrote:
 I recently acquired a CanoScan LiDE 60.
 
 It basically works but it is very unstable: It often stops during the
 scan and sane returns an error, or it just hangs during the scan (making
 ugly noises). The only remedy is to re-plug the usb cable. (which
 sometimes causes a panic)
 
 I tried on my notebook which is running a recent current. It works
 flawlessly there - not a single error so far.
 
 So I upgraded my main computer to 6.1-PRERELEASE but the problem
 persists:
 
 - Are there any usb/ehci fixes in CURRENT that haven't made it to
 6-stable yet? (I really don't want to update the machine that's making
 troubles to current)
 
 - Or is this more likely to be chipset related (the notebook dmesg shows
 Intel 82801DB/L/M (ICH4) USB 2.0 controller vs VIA on the computer
 that causes troubles)
 
 Also, it occured to me that this could be power related - the scanner
 doesn't require an external power suppply. I tried different USB ports
 but didn't notice any difference.
 
 dmesg can be found here:
Here's the location:
http://stud4.tuwien.ac.at/~e0125637/fbsd/dmesg

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]