Re: User's cron job creates zombie process on 5.3
On Wed, 2005-Jan-19 21:14:26 -0800, spam maps wrote:
( /usr/bin/ssh -n -f ${tunnel} )
Alas, no success. Still get the defunct zombie
process.
I actually wonder if this is an odd or buggy behaviour
of ssh, or is cron making a mistake here?
The cron daemon (which will have a PPID of 1) forks a copy of itself
to actually handle the cron job (I suspect this is the parent of the
zombie that you are seeing). This child process runs /bin/sh -c CRONJOB
(where CRONJOB is the line in your crontab) and I suspect this is the
zombie you are seeing.
My guess is that your ssh process is holding open file descriptors and
the cron child process is waiting for these descriptors to close before
wait()ing for the child. If this is true, then you should avoid it
with something like:
( /usr/bin/ssh -n -f ${tunnel} /dev/null 21 )
(or redirect to a suitable file).
Leaving a zombie process around, means there's a kind
of bug/mistake somewhere, right?
Yes. But it's not necessarily a bug in FreeBSD :-).
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Very large directory
On Wed, 2005-Jan-19 21:30:53 -0600, Phillip Salzman wrote:
They've been running for a little while now - and recently we've noticed a
lot of disk space disappearing. Shortly after that, a simple du into our
/var/spool returned a not so nice error:
du: fts_read: Cannot allocate memory
No matter what command I run on that directory, I just don't seem to have
enough available resources to show the files let alone delete them (echo *,
ls, find, rm -rf, etc.)
I suspect you will need to write something that uses dirent(3) to scan
the offending directory and delete (or whatever) the files one by one.
Skeleton code (in perl) would look like:
chdir $some_dir or die Can't cd $some_dir: $!;
opendir(DIR, .) or die Can't opendir: $!;
while (my $file = readdir(DIR)) {
next if ($file eq '.' || $file eq '..');
next if (this_file_is_still_needed($file));
unlink $file or warn Unable to delete $file: $!;
}
closedir DIR;
If you've reached the point where you can't actually read the entire
directory into user memory, expect the cleanup to take quite a while.
Once you've finished the cleanup, you should confirm that the directory
has shrunk to a sensible size. If not, you need to re-create the
directory and move the remaining files into the new directory.
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: User's cron job creates zombie process on 5.3
Peter Jeremy wrote:
On Wed, 2005-Jan-19 21:14:26 -0800, spam maps wrote:
( /usr/bin/ssh -n -f ${tunnel} )
Alas, no success. Still get the defunct zombie
process.
I actually wonder if this is an odd or buggy
behaviour of ssh, or is cron making a mistake here?
The cron daemon (which will have a PPID of 1) forks
a copy of itself to actually handle the cron job
(I suspect this is the parent of the zombie that
you are seeing). This child process runs
/bin/sh -c CRONJOB (where CRONJOB is the line in
your crontab) and I suspect this is the zombie you
are seeing.
My guess is that your ssh process is holding open
file descriptors and the cron child process is
waiting for these descriptors to close before
wait()ing for the child. If this is true, then you
should avoid it with something like:
( /usr/bin/ssh -n -f ${tunnel} /dev/null 21 )
BINGO!
That works. Zombie has gone. Thank you.
Leaving a zombie process around, means there's a
kind
of bug/mistake somewhere, right?
Yes. But it's not necessarily a bug in FreeBSD :-).
So, after you've given me a complicated solution to
avoid the zombie, can you tell which program is at
error here? Cron, ssh, or FreeBSD?
Rob.
__
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: User's cron job creates zombie process on 5.3
On Thu, 20 Jan 2005, spam maps wrote:
Peter Jeremy wrote:
On Wed, 2005-Jan-19 21:14:26 -0800, spam maps wrote:
( /usr/bin/ssh -n -f ${tunnel} )
Alas, no success. Still get the defunct zombie
process.
I actually wonder if this is an odd or buggy
behaviour of ssh, or is cron making a mistake here?
The cron daemon (which will have a PPID of 1) forks
a copy of itself to actually handle the cron job
(I suspect this is the parent of the zombie that
you are seeing). This child process runs
/bin/sh -c CRONJOB (where CRONJOB is the line in
your crontab) and I suspect this is the zombie you
are seeing.
My guess is that your ssh process is holding open
file descriptors and the cron child process is
waiting for these descriptors to close before
wait()ing for the child. If this is true, then you
should avoid it with something like:
( /usr/bin/ssh -n -f ${tunnel} /dev/null 21 )
BINGO!
That works. Zombie has gone. Thank you.
Leaving a zombie process around, means there's a
kind
of bug/mistake somewhere, right?
Yes. But it's not necessarily a bug in FreeBSD :-).
So, after you've given me a complicated solution to
avoid the zombie, can you tell which program is at
error here? Cron, ssh, or FreeBSD?
There are two other possibilities I could thing of off hand;
Bourne Shell, or indeed, the 'program' (albeit a small one) which
you wrote! My vote would be the latter. I vote that way because
a change in the code (based on a good knowledge of the mechanics
of the language and unix in general) made the problem go away.
It's mainly a matter of perspective I guess :)
Thanks,
- Tom
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Very large directory
Peter Jeremy [EMAIL PROTECTED] wrote: On Wed, 2005-Jan-19 21:30:53 -0600, Phillip Salzman wrote: They've been running for a little while now - and recently we've noticed a lot of disk space disappearing. Shortly after that, a simple du into our /var/spool returned a not so nice error: du: fts_read: Cannot allocate memory No matter what command I run on that directory, I just don't seem to have enough available resources to show the files let alone delete them (echo *, ls, find, rm -rf, etc.) I suspect you will need to write something that uses dirent(3) to scan the offending directory and delete (or whatever) the files one by one. Skeleton code (in perl) would look like: [...] I would suggest trying this simple hack: cd /var/spool/directory ; cat . | strings | xargs rm -f It's a dirty hack, but might work, if the file names in that directory aren't too strange (no spaces etc.). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[no subject]
___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Persisting troubles with periodic stalls every few minutes
On Thu, 2005-01-20 at 02:36 +0100, Bartosz Fabianowski wrote: Hi list, I have been having a lot of trouble with performance on my laptop, which I first set up with 5.3-RELEASE and constantly keep up to date with 5.3-STABLE. The box runs stable, but periodically, somewhere between every few minutes down to every few seconds, it stalls for 5 seconds. By that I mean that the screen is not being refreshed and all keyboard strokes go into some kind of buffer to get processed when the stall is over. Some key strokes also get lost or reversed in order, which makes this even more annoying. The trouble is that I cannot figure out how to find the responsible process. Tools such as top(1) update in one second intervals at best and as there are no screen updates during the stall, so they produce nothing useful. The only tool that gave me some kind of information was systat(1). When I invoke systat -vmstat 1, I see the following: Try running top with the -q option, and/or pressing space (which causes top to try and refresh immediately). If you still can't get any screen updates to happen during the freeze, try top -qbSs 1 -d max /var/tmp/somefile And look through the file to see if you can establish what was actually happening at the time of the freeze. Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange ucom (uplcom) error
I wrote:
Emanuel Strobl wrote:
Am Dienstag, 18. Januar 2005 16:17 schrieb Andrew L. Neporada:
On Tue, Jan 18, 2005 at 01:06:43PM +0100, Emanuel Strobl wrote:
Dear experts,
I have two USB-RS232 Adaptors, both with PL2303 chipset. One is working
the other one not (I hate to say it but both are working under win).
The not working (more expensive) one gets recognized as ucom0 and I have
ucom0, also I can receive signal but not transmit.
[skip]
Take a look at http://gate.intercaf.ru/~lesha/6100/ and try patch
http://gate.intercaf.ru/~lesha/6100/pl2303x.patch
It can break old (working) PL2303 chip, but it works for me with newer
Thanks a lot, this indeed fixes the revision 3.0 adaptor but unfortunately
also breakes the 2.02 version :(
Perhaps there's a goog guy out there who can refurbish the uplcom driver
with
this information (akiyama?)?
Thanks a lot,
I've just recently been looking into this too. I used the mentioned
patch and also linux driver source and have come with the attached
patch. It contains one more change but I don't know if it's correct. It
works for both chips on CURRENT for serial console. It detects if the
chip is rev 3.00 and aplies the patch only for it.
The author of the patch mentions it isn't binary safe - sometimes the
chip stops working. I planned to test it with binary transfers (ppp)
today, check if it's working and submit it (with some cleanup) for
inclusion in FreeBSD.
Michal Mertl
I tested my patch for binary safety on CURRENT yesterday (dialed with
ppp) and didn't notice any problem.
I'm attaching my patch again because some recipients didn't probably
receive it yesterday.
Michal
Index: uplcom.c
===
RCS file: /home/fcvs/cvs/src/sys/dev/usb/uplcom.c,v
retrieving revision 1.25
diff -u -r1.25 uplcom.c
--- uplcom.c 6 Jan 2005 01:43:29 - 1.25
+++ uplcom.c 20 Jan 2005 13:15:40 -
@@ -97,10 +97,13 @@
#include sys/sysctl.h
#include sys/uio.h
+#include machine/bus.h
+
#include dev/usb/usb.h
#include dev/usb/usbcdc.h
#include dev/usb/usbdi.h
+#include dev/usb/usbdivar.h
#include dev/usb/usbdi_util.h
#include usbdevs.h
#include dev/usb/usb_quirks.h
@@ -113,30 +116,34 @@
SYSCTL_INT(_hw_usb_uplcom, OID_AUTO, debug, CTLFLAG_RW,
uplcomdebug, 0, uplcom debug level);
-#define DPRINTFN(n, x) do { \
+#define DPRINTFN(n, x) do { \
if (uplcomdebug (n)) \
logprintf x; \
} while (0)
#else
-#define DPRINTFN(n, x)
+#define DPRINTFN(n, x)
#endif
-#define DPRINTF(x) DPRINTFN(0, x)
+#define DPRINTF(x) DPRINTFN(0, x)
-#define UPLCOM_MODVER 1 /* module version */
+#define UPLCOM_MODVER 1 /* module version */
#define UPLCOM_CONFIG_INDEX 0
#define UPLCOM_IFACE_INDEX 0
#define UPLCOM_SECOND_IFACE_INDEX 1
#ifndef UPLCOM_INTR_INTERVAL
-#define UPLCOM_INTR_INTERVAL 100 /* ms */
+#define UPLCOM_INTR_INTERVAL 100 /* ms */
#endif
#define UPLCOM_SET_REQUEST 0x01
#define UPLCOM_SET_CRTSCTS 0x41
-#define RSAQ_STATUS_CTS 0x80
-#define RSAQ_STATUS_DSR 0x02
-#define RSAQ_STATUS_DCD 0x01
+#define UPLCOM_SET_CRTSCTS_2303X 0x61
+#define RSAQ_STATUS_CTS 0x80
+#define RSAQ_STATUS_DSR 0x02
+#define RSAQ_STATUS_DCD 0x01
+
+#define CHIPTYPE_PL2303 0
+#define CHIPTYPE_PL2303X 1
struct uplcom_softc {
struct ucom_softc sc_ucom;
@@ -156,14 +163,15 @@
u_char sc_lsr; /* Local status register */
u_char sc_msr; /* uplcom status register */
+ int sc_chiptype;
};
/*
* These are the maximum number of bytes transferred per frame.
* The output buffer size cannot be increased due to the size encoding.
*/
-#define UPLCOMIBUFSIZE 256
-#define UPLCOMOBUFSIZE 256
+#define UPLCOMIBUFSIZE 256
+#define UPLCOMOBUFSIZE 256
Static usbd_status uplcom_reset(struct uplcom_softc *);
Static usbd_status uplcom_set_line_coding(struct uplcom_softc *,
@@ -299,6 +307,7 @@
char *devinfo;
const char *devname;
usbd_status err;
+ usb_device_descriptor_t *udd;
int i;
devinfo = malloc(1024, M_USBDEV, M_WAITOK);
@@ -374,7 +383,14 @@
sc-sc_isize = UGETW(ed-wMaxPacketSize);
}
}
-
+ udd = dev-ddesc;
+ if (UGETW(udd-bcdDevice) == 0x300) {
+ DPRINTF((chiptype 2303X\n));
+ sc-sc_chiptype = CHIPTYPE_PL2303X;
+ } else {
+ DPRINTF((chiptype 2303\n));
+ sc-sc_chiptype = CHIPTYPE_PL2303;
+ }
if (sc-sc_intr_number == -1) {
printf(%s: Could not find interrupt in\n,
USBDEVNAME(ucom-sc_dev));
@@ -617,7 +633,10 @@
req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
req.bRequest = UPLCOM_SET_REQUEST;
USETW(req.wValue, 0);
- USETW(req.wIndex, UPLCOM_SET_CRTSCTS);
+ if (sc-sc_chiptype == CHIPTYPE_PL2303X)
+ USETW(req.wIndex, UPLCOM_SET_CRTSCTS_2303X);
+ else
+ USETW(req.wIndex, UPLCOM_SET_CRTSCTS);
USETW(req.wLength, 0);
err = usbd_do_request(sc-sc_ucom.sc_udev, req, 0);
@@ -713,6 +732,43 @@
return (0);
}
+#define DO_REQ(type, reQ, wVal, wInd) do {\
+
Re: twa breakage on AMD64with9.1.5.23wareversionand2005-01-1103:00:49 UTC RELENG_5 commit
looks like patch3 worked, good job! I had to turn off TWA_DEBUG to get the boot going, the debug was starving the boot on a 9600 baud terminal. I can increase the speed and caputer the output on monday if it will help(it on the large side, bigger than the 10,000 line capture buffer in am using). I incude 2 iozone reports, the first one the new driver the second one the old driver, Is thier a way to increase the read ahead in freebsd?? -mjm iozone -s 20480m -r 60 -i 0 -i 1 -t 1 Iozone: Performance Test of File I/O Version $Revision: 3.196 $ Compiled for 64 bit mode. Build: freebsd Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Jean-Marc Zucconi, Jeff Blomberg. Run began: Thu Jan 20 07:45:52 2005 File size set to 20971520 KB Record Size 60 KB Command line used: iozone -s 20480m -r 60 -i 0 -i 1 -t 1 Output is in Kbytes/sec Time Resolution = 0.01 seconds. Processor cache size set to 1024 Kbytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. Throughput test with 1 process Each process writes a 20971520 Kbyte file in 60 Kbyte records Children see throughput for 1 initial writers = 78219.47 KB/sec Parent sees throughput for 1 initial writers = 78060.45 KB/sec Min throughput per process = 78219.47 KB/sec Max throughput per process = 78219.47 KB/sec Avg throughput per process = 78219.47 KB/sec Min xfer= 20971500.00 KB Children see throughput for 1 rewriters= 19394.53 KB/sec Parent sees throughput for 1 rewriters = 19394.32 KB/sec Min throughput per process = 19394.53 KB/sec Max throughput per process = 19394.53 KB/sec Avg throughput per process = 19394.53 KB/sec Min xfer= 20971500.00 KB Children see throughput for 1 readers = 55960.09 KB/sec Parent sees throughput for 1 readers = 55954.25 KB/sec Min throughput per process = 55960.09 KB/sec Max throughput per process = 55960.09 KB/sec Avg throughput per process = 55960.09 KB/sec Min xfer= 20971500.00 KB Children see throughput for 1 re-readers= 55948.26 KB/sec Parent sees throughput for 1 re-readers = 55946.60 KB/sec Min throughput per process = 55948.26 KB/sec Max throughput per process = 55948.26 KB/sec Avg throughput per process = 55948.26 KB/sec Min xfer= 20971500.00 KB iozone test complete. iozone -s 20480m -r 60 -i 0 -i 1 -t 1 Iozone: Performance Test of File I/O Version $Revision: 3.196 $ Compiled for 64 bit mode. Build: freebsd Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Jean-Marc Zucconi, Jeff Blomberg. Run began: Mon Dec 20 21:03:36 2004 File size set to 20971520 KB Record Size 60 KB Command line used: iozone -s 20480m -r 60 -i 0 -i 1 -t 1 Output is in Kbytes/sec Time Resolution = 0.01 seconds. Processor cache size set to 1024 Kbytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. Throughput test with 1 process Each process writes a 20971520 Kbyte file in 60 Kbyte records Children see throughput for 1 initial writers = 78738.67 KB/sec Parent sees throughput for 1 initial writers = 78716.55 KB/sec Min throughput per process = 78738.67 KB/sec Max throughput per process = 78738.67 KB/sec Avg throughput per process = 78738.67 KB/sec Min xfer= 20971500.00 KB Children see throughput for 1 rewriters= 32126.46 KB/sec Parent sees throughput for 1 rewriters = 32125.77 KB/sec Min throughput per process = 32126.46 KB/sec Max throughput per process
Re: Very large directory
From: Phillip Salzman [EMAIL PROTECTED] Subject: Very large directory I have a pair of servers that act as SMTP/AV gateways. It seems that even though we've told the AV software not to store messages, it is anyway. They've been running for a little while now - and recently we've noticed a lot of disk space disappearing. Shortly after that, a simple du into our /var/spool returned a not so nice error: du: fts_read: Cannot allocate memory No matter what command I run on that directory, I just don't seem to have enough available resources to show the files let alone delete them (echo *, ls, find, rm -rf, etc.) Even echo * sorts the output, and the sorting consumes a large amount of resources. Try and ls with a -f option. To prove it to yourself take any directory and perform echo * and then do the same with ls -f I first noticed this years ago when on an old SysV I had a directory that took 5 minutes to display and the ls -f was quite fast. End of freebsd-stable Digest, Vol 95, Issue 8 -- Bill Vermillion - bv @ wjv . com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Very large directory
Peter Jeremy wrote:
On Wed, 2005-Jan-19 21:30:53 -0600, Phillip Salzman wrote:
They've been running for a little while now - and recently we've noticed a
lot of disk space disappearing. Shortly after that, a simple du into our
/var/spool returned a not so nice error:
du: fts_read: Cannot allocate memory
No matter what command I run on that directory, I just don't seem to have
enough available resources to show the files let alone delete them (echo *,
ls, find, rm -rf, etc.)
I suspect you will need to write something that uses dirent(3) to scan
the offending directory and delete (or whatever) the files one by one.
Skeleton code (in perl) would look like:
chdir $some_dir or die Can't cd $some_dir: $!;
opendir(DIR, .) or die Can't opendir: $!;
while (my $file = readdir(DIR)) {
next if ($file eq '.' || $file eq '..');
next if (this_file_is_still_needed($file));
unlink $file or warn Unable to delete $file: $!;
}
closedir DIR;
similarly,
opendir(DIR, $some_dir ) or die Can't open dir $some_dir: $!;
while ( defined(my $file = readdir(DIR))) {
print $file\n unless ($file eq '.' || $file eq '..');
}
closedir(DIR);
...will print the files one per line, which can be piped to more or
redirected to another file. This will let you get a feel for the names
of the files in the directory. It could then be cleaned up with various
pipelines like egrep 'foo|bar|rat' | xargs rm
Note: you want to wrap the my $file = readdir(DIR) in a defined(),
otherwise your loop will exit early if you come across a file named 0
(zero).
David
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Very large directory
Oliver Fromme wrote: Peter Jeremy [EMAIL PROTECTED] wrote: On Wed, 2005-Jan-19 21:30:53 -0600, Phillip Salzman wrote: They've been running for a little while now - and recently we've noticed a lot of disk space disappearing. Shortly after that, a simple du into our /var/spool returned a not so nice error: du: fts_read: Cannot allocate memory No matter what command I run on that directory, I just don't seem to have enough available resources to show the files let alone delete them (echo *, ls, find, rm -rf, etc.) I suspect you will need to write something that uses dirent(3) to scan the offending directory and delete (or whatever) the files one by one. Skeleton code (in perl) would look like: [...] I would suggest trying this simple hack: cd /var/spool/directory ; cat . | strings | xargs rm -f It's a dirty hack, but might work, if the file names in that directory aren't too strange (no spaces etc.). why suggest a dirty hack that might not work, when the proposed Perl script would have worked perfectly? David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Very large directory
David Landgren [EMAIL PROTECTED] wrote: Oliver Fromme wrote: I would suggest trying this simple hack: cd /var/spool/directory ; cat . | strings | xargs rm -f It's a dirty hack, but might work, if the file names in that directory aren't too strange (no spaces etc.). why suggest a dirty hack that might not work, when the proposed Perl script would have worked perfectly? In this case, the hack _should_ work, and is about 1/10 of the size of the perl script and leaves a lot less room for typing errors. Aport from that, perl might not even be installed on the machine in question, who knows. But of course: YMMV. It was just a suggestion. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind. -- Alan Kay, OOPSLA '97 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ciss(4) adapter not recognized (Compaq/HP Smart Array 6i/64xx)
Hi, We've got a new Compaq/HP server machine, but there are problems installing FreeBSD because the RAID controller is not recognized. It's a CISS 6i (according to the specs) which I expected to be recognized by the ciss(4) driver. But unfortunately, it isn't. This is the output from dmesg: pci2: unknown card (vendor=0x0e11, dev=0x0046) at 1.0 irq 5 According to pciids.sourceforge.net, 0e11 is Compaq, and 0046 is their ID for the Smart Array 64xx. It is not in the list of supported IDS in src/sys/dev/ciss/ciss.c. Would it work to just add that ID to the list, compile a kernel, and then use that kernel to boot the installation? (I don't have time for many experiments, because the box is installed in a computing centre which is not exactly nearby. That's why I'm asking here first, instead of just trying to insert that ID in the source.) I'm wondering if the device ID is really correct. All the other IDs in the ciss.c source are in the 0x40XX range. 0x0046 seems pretty odd. Also, there's a CISS_BOARD flag associated with each of the devices. Should I set it to SA5 or SA5B for the new ID? (My guess would be SA5, but I could be wrong.) Any hints and advice would be greatly appreciated! Best regards Oliver PS: I'm using 4-stable, but I checked the CVS repository and verified that the device ID is neither in 5-stable nor HEAD. Searching for this device in the list archives gave zero hits. -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. I have stopped reading Stephen King novels. Now I just read C code instead. -- Richard A. O'Keefe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failure on today's CVS (stable, AMD)
On Wed, 19 Jan 2005 16:42:29 -0500, Michael R. Wayne [EMAIL PROTECTED] wrote: 2) More importantly, I recovered by loading /boot/kernel.old/kernel and the box is up BUT I am concerned that the NEXT time that I do make installkernel I'll stomp on kernel.old losing this fallback procedure. I can certainly copy /boot/kernel.old to /boot/kernel.save but is there something else I should save? Or is there another suggested procedure? When I have a bad kernel I do the following after booting the good kernel. cd /boot rm -rf kernel cp -rp kernel.old kernel cp -rp kernel.old kernel.good This way I can reboot the box without going into the loader to load kernel.old. Scot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad disk or kernel (ATA Driver) problem? - SOLVED
Karl Denninger [EMAIL PROTECTED] wrote: These two are DiamondMax10s - let's hope that this doesn't apply to that line as well. Out of curiosity, why didn't you consider Seagate ? The recent Maxtors that I have, if run 24x7, seem to die just after the warranty expires (for me, just over a year). I'm now switching back to Seagate, as they now have a nice 5-year warranty, but I don't have much experience with these new drives. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Realtek 8139 (rl) very poor performance
Hi all, I'm havin' a strange problem with my Realtek Network Adapter. On boot, the detection looks just fine: $ dmesg| grep rl rl0: RealTek 8139 10/100BaseTX port 0xd000-0xd0ff mem 0xee00-0xeeff irq 10 at device 10.0 on pci0 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:40:f4:32:e5:12 However, the performance is very poor. Some examples: * using 'fetch' command, I get a lot of timeouts, so some ports fail to install (I have to retry). * using Konqueror, for instance, I also get some timeouts and a very low speed connecting to different websites. I've done the some test on the same machine (and on my laptop) using GNU/Linux, and works pretty fine. So I discarded a network hardware issue as the origin of the problem. Any ideas? Thank you all in advance. -- Imobach González Sosa imobachgs en banot punto net osoh en jabber.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failure on today's CVS (stable, AMD)
Hi, Michael, 2005-01-19 16:42 -0500Michael R. Wayne 2) More importantly, I recovered by loading /boot/kernel.old/kernel and the box is up BUT I am concerned that the NEXT time that I do make installkernel I'll stomp on kernel.old losing this fallback procedure. I can certainly copy /boot/kernel.old to /boot/kernel.save but is there something else I should save? Or is there another suggested procedure? I personally do: cp -R /boot/kernel /boot/kernel.good If the kernel has provided stability for 30 days. For your case, you may want to do: cp -R /boot/kernel.old /boot/kernel.good since the kernel.old is last known good kernel. Of course kernel.save is a good name. For a STABLE branch you generally won't need to fear that loader changes can prevent you from being able to boot from older kernels. Therefore, I think the procedure you have listed is enough to do. Cheers, -- Xin LI delphij delphij net http://www.delphij.net/ signature.asc Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8?= =?UTF-8?Q?=E5=88=86?=
Re: Bad disk or kernel (ATA Driver) problem?
At 04:13 PM 19/01/2005, Karl Denninger wrote: I'm having a lot of trouble believing this is an actual disk problem. Among other things, its happening at different places - not always at the same block. If you have the drives on a RELENG_5 box, try /usr/ports/sysutils/smartmontools/ Its quite handy to sort of various drive issues as well as to monitor for ongoing errors via the daemon. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFLAGS=-O2 -pipe problems in RELENG_5 ?
On 18-Jan-2005 Chris wrote: I have been compiling ports using -O2 since I started using FreeBSD back in 2003 and only port that has had issues with this is lang/ezm3 in FreeBSD 5.2.1 it needed -O. I fixed that at the beginning of November. John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek 8139 (rl) very poor performance
Hi! I had some problems with rl cards with auto media. It happens with some kind of hubs. Try to specify type of your network media, for example: # ifconfig rl0 inet 10.0.0.5 netmask 255.255.255.0 media 100baseTX mediaopt full-duplex # route add default 10.0.0.254 Vlad. From [EMAIL PROTECTED] Thu Jan 20 11:31:23 2005 From: Imobach =?iso-8859-1?q?Gonz=E1lez_Sosa?= [EMAIL PROTECTED] To: freebsd-stable@freebsd.org Date: Thu, 20 Jan 2005 16:30:03 + Subject: Realtek 8139 (rl) very poor performance Hi all, I'm havin' a strange problem with my Realtek Network Adapter. On boot, the detection looks just fine: $ dmesg| grep rl rl0: RealTek 8139 10/100BaseTX port 0xd000-0xd0ff mem 0xee00-0xeeff irq 10 at device 10.0 on pci0 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:40:f4:32:e5:12 However, the performance is very poor. Some examples: * using 'fetch' command, I get a lot of timeouts, so some ports fail to install (I have to retry). * using Konqueror, for instance, I also get some timeouts and a very low speed connecting to different websites. I've done the some test on the same machine (and on my laptop) using GNU/Linux, and works pretty fine. So I discarded a network hardware issue as the origin of the problem. Any ideas? Thank you all in advance. -- Imobach González Sosa imobachgs en banot punto net osoh en jabber.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: User's cron job creates zombie process on 5.3
Date: Thu, 20 Jan 2005 02:06:38 -0800 (PST)
From: spam maps [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Peter Jeremy wrote:
On Wed, 2005-Jan-19 21:14:26 -0800, spam maps wrote:
( /usr/bin/ssh -n -f ${tunnel} )
Alas, no success. Still get the defunct zombie
process.
I actually wonder if this is an odd or buggy
behaviour of ssh, or is cron making a mistake here?
The cron daemon (which will have a PPID of 1) forks
a copy of itself to actually handle the cron job
(I suspect this is the parent of the zombie that
you are seeing). This child process runs
/bin/sh -c CRONJOB (where CRONJOB is the line in
your crontab) and I suspect this is the zombie you
are seeing.
My guess is that your ssh process is holding open
file descriptors and the cron child process is
waiting for these descriptors to close before
wait()ing for the child. If this is true, then you
should avoid it with something like:
( /usr/bin/ssh -n -f ${tunnel} /dev/null 21 )
BINGO!
That works. Zombie has gone. Thank you.
Leaving a zombie process around, means there's a
kind
of bug/mistake somewhere, right?
Yes. But it's not necessarily a bug in FreeBSD :-).
So, after you've given me a complicated solution to
avoid the zombie, can you tell which program is at
error here? Cron, ssh, or FreeBSD?
FreeBSD is an operating system, not a kernel like Linux. Both cron and
ssh are part of FreeBSD. That said, the problem could be in sh or in the
program executed, too.
I trivial note: -f implies -n. There is no need to specify both, but no
harm in doing so.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek 8139 (rl) very poor performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 20 Jan 2005 12:08:16 -0500 (EST), Vladimir Pianykh [EMAIL PROTECTED] wrote: I had some problems with rl cards with auto media. You're probably not the only one. Note this comment from sys/pci/if_rl.c /* * The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is * probably the worst PCI ethernet controller ever made, with the possible * exception of the FEAST chip made by SMC. The 8139 supports bus-master * DMA, but it has a terrible interface that nullifies any performance * gains that bus-master DMA usually offers. - -- G. Stewart - [EMAIL PROTECTED] Sign spotted outside a second hand shop: WE EXCHANGE ANYTHING - BICYCLES, WASHING MACHINES, ETC. WHY NOT BRING YOUR WIFE ALONG AND GET A WONDERFUL BARGAIN? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB7+s4K5oiGLo9AcYRAhFnAJwMVwWjqVG9GgvD4uqqx2kotqB8aACcD7N4 64wIPwIEKgzzQmJgdMn58UU= =17Dp -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Very large directory
Thanks Peter (along with everyone else who's responded.)
I've received a couple perl scripts from a few different people. I can't
use any of them until this evening due to the current load of the machines
though. Last night I ended up doing a strings on the directory, and taking
its output into a for loop removing the files.
--
Phillip Salzman
-Original Message-
From: Peter Jeremy [mailto:[EMAIL PROTECTED]
Sent: January 20, 2005 3:46 AM
To: Phillip Salzman
Cc: [EMAIL PROTECTED]
Subject: Re: Very large directory
On Wed, 2005-Jan-19 21:30:53 -0600, Phillip Salzman wrote:
They've been running for a little while now - and recently we've
noticed a lot of disk space disappearing. Shortly after
that, a simple
du into our /var/spool returned a not so nice error:
du: fts_read: Cannot allocate memory
No matter what command I run on that directory, I just don't seem to
have enough available resources to show the files let alone delete
them (echo *, ls, find, rm -rf, etc.)
I suspect you will need to write something that uses
dirent(3) to scan the offending directory and delete (or
whatever) the files one by one.
Skeleton code (in perl) would look like:
chdir $some_dir or die Can't cd $some_dir: $!;
opendir(DIR, .) or die Can't opendir: $!;
while (my $file = readdir(DIR)) {
next if ($file eq '.' || $file eq '..');
next if (this_file_is_still_needed($file));
unlink $file or warn Unable to delete $file: $!;
}
closedir DIR;
If you've reached the point where you can't actually read the
entire directory into user memory, expect the cleanup to take
quite a while.
Once you've finished the cleanup, you should confirm that the
directory has shrunk to a sensible size. If not, you need to
re-create the directory and move the remaining files into the
new directory.
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failure on today's CVS (stable, AMD)
Date: Thu, 20 Jan 2005 10:12:04 -0600 From: Scot Hetzel [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] On Wed, 19 Jan 2005 16:42:29 -0500, Michael R. Wayne [EMAIL PROTECTED] wrote: 2) More importantly, I recovered by loading /boot/kernel.old/kernel and the box is up BUT I am concerned that the NEXT time that I do make installkernel I'll stomp on kernel.old losing this fallback procedure. I can certainly copy /boot/kernel.old to /boot/kernel.save but is there something else I should save? Or is there another suggested procedure? When I have a bad kernel I do the following after booting the good kernel. cd /boot rm -rf kernel cp -rp kernel.old kernel cp -rp kernel.old kernel.good This way I can reboot the box without going into the loader to load kernel.old. While this works (I've done it), make reinstallkernel and make -DMODULES_WITH_WORLD reinstallkernel can also be good friends. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange ucom (uplcom) error
Am Donnerstag, 20. Januar 2005 14:18 schrieb Michal Mertl: works for both chips on CURRENT for serial console. It detects if the chip is rev 3.00 and aplies the patch only for it. The author of the patch mentions it isn't binary safe - sometimes the chip stops working. I planned to test it with binary transfers (ppp) today, check if it's working and submit it (with some cleanup) for inclusion in FreeBSD. Michal Mertl I tested my patch for binary safety on CURRENT yesterday (dialed with ppp) and didn't notice any problem. Thanks a lot, unfortunately my notebook died (the display mechanic) so I cannot test it at the moment (my workstation box is too far away from my servers with serial stuff). But I think this should be commited, otherwiese more people like me go shopping, testing the adaptor, seeing that it gets recognized as Prolific 2303, purchasing some of them and then at home find out that there is also a unsupported version of the 2303 :( I'm sure someone (bernd?) will commit it for you. Thanks a lot for your work, I'll test it asap and let you know if I find anything unusual. Best regards, -Harry I'm attaching my patch again because some recipients didn't probably receive it yesterday. Michal pgp7Z1v5WRGhZ.pgp Description: PGP signature
fwe and em ftp transfer rates
Dear all, I'm sorry but I have to report something's going wrong with simple ftp file transfers. I have two Fujitsu Siemens Primergy B125 servers ([EMAIL PROTECTED], 512MB) with both 'em' cards in it which are connected directly together, so no switch can drop packets. When I transfer a large testfile (400MB) via ftp I get unbelievable 18MB/s. Both servers are 0% idle (~60% intr 40% sys). What the heck is this machine doing? There's nothing else on the machines running, sure! I can dump to the disks with ~55MB/s so the bottleneck is not the hardware. Things go worse if I use fwe (TI chipest) or fwip instead of em. Then transfer rates decrease to 15MB/s for the fwe and 13MB/s with the fwip. One good thin is that using NFS instead of ftp gives comparable transfer rates (~5% less) without tuning and regardless of udp or tcp. world an kernel are built with -O2 -march=pentium3, kernel config and dmesg are attached (CUV-LV ist the kernel config). What can I do to get reasonable GbE performance (with this hw I expect at least 40MB/s, it's what a friend achieves with an other graphical OS on similar hw). Thanks, -Harry Copyright (c) 1992-2005 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 5.3-STABLE #0: Thu Jan 20 02:12:36 CET 2005 [EMAIL PROTECTED]:/builder/obj/builder/src/sys/CUV-LV Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (870.58-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 536854528 (511 MB) avail memory = 515629056 (491 MB) acpi0: ASUS CUV_LV on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 cpu0: ACPI CPU (3 Cx states) on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 82C691 (Apollo Pro) host to PCI bridge mem 0xfe00-0xfe3f at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686A UDMA66 controller port 0xb800-0xb80f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 4.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: VIA 83C572 USB controller port 0xb400-0xb41f irq 12 at device 4.2 on pci0 uhci0: [GIANT-LOCKED] 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 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xb000-0xb01f irq 12 at device 4.3 on pci0 uhci1: [GIANT-LOCKED] 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 uhub1: 2 ports with 2 removable, self powered viapropm0: SMBus I/O base at 0xe800 viapropm0: VIA VT82C686A Power Management Unit port 0xe800-0xe80f at device 4.4 on pci0 viapropm0: SMBus revision code 0x0 smbus0: System Management Bus on viapropm0 smb0: SMBus generic I/O on smbus0 fxp0: Intel 82559 Pro/100 Ethernet port 0xa800-0xa83f mem 0xfa80-0xfa8f,0xfb00-0xfb000fff irq 5 at device 7.0 on pci0 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:e0:18:06:ad:59 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xa400-0xa43f mem 0xf980-0xf981,0xfa00-0xfa01 irq 10 at device 9.0 on pci0 em0: Ethernet address: 00:0e:0c:34:2b:f8 em0: Speed:N/A Duplex:N/A fwohci0: Texas Instruments TSB43AB23 mem 0xf880-0xf8803fff,0xf900-0xf90007ff irq 12 at device 10.0 on pci0 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:01:08:00:20:01:eb:10 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet address: 02:01:08:01:eb:10 fwe0: Ethernet address: 02:01:08:01:eb:10 fwe0: if_start running deferred for Giant sbp0: SBP-2/SCSI over FireWire on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop = 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) atapci1: HighPoint HPT372 UDMA133 controller port 0x8800-0x88ff,0x9000-0x9003,0x9400-0x9407,0x9800-0x9803,0xa000-0xa007 irq 11 at device 12.0 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3
Re: Realtek 8139 (rl) very poor performance
On Thu, 20 Jan 2005 16:30:03 +, Imobach González Sosa wrote Hi all, I'm havin' a strange problem with my Realtek Network Adapter. On boot, the detection looks just fine: $ dmesg| grep rl rl0: RealTek 8139 10/100BaseTX port 0xd000-0xd0ff mem 0xee00- 0xeeff irq 10 at device 10.0 on pci0 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:40:f4:32:e5:12 However, the performance is very poor. Some examples: * using 'fetch' command, I get a lot of timeouts, so some ports fail to install (I have to retry). * using Konqueror, for instance, I also get some timeouts and a very low speed connecting to different websites. I've done the some test on the same machine (and on my laptop) using GNU/Linux, and works pretty fine. So I discarded a network hardware issue as the origin of the problem. If it's on an old machine then you have your problem there. The Realtek chips and its drivers put everything on the CPU, because the chip is not capable of doing too much. Which is why it's so cheap. Modern CPUs don't have too much problems with it, but older ones do. Of course, the Linux driver might be a bit better written then the FreeBSD one. It's advicable to get yourself a better network card if it's indeed an old machine. Cheers, Jorn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Higher ATA-Mode - lower speed
Dear ata interested guys, I observed a strange behaviour which seems to explain my often noticed 16MB/s hard-limit I have a UDMA133 drive (MAXTOR 6L060J3) which saturates at 16MB/s when I dump anything to it, regardless of the block size. This transfer rate is reached with bs=4k and doesn't increase any more even not with bs=64k. Now, when I set the mode to UDMA100 I get well over 40MB/s Can anybody confirm that for different hw? Especially people like fandino who already discussed poor ata performance on -current (~16 Oct. 04). Why does UDMA133 mode limit the transfer speed so badly? And why do I get significantly slower transfer rates (32MB/s insted of 42MB/s) when I set the mode to UDMA66 (compared to UDMA100 but twice the speed of UDMA133)? There's only one device on the channel, so UDMA66 should be fine for 42MB/s. The controller is a HPT372. Best regards, -Harry pgpGEJ1qXmSgv.pgp Description: PGP signature
Re: CFLAGS=-O2 -pipe problems in RELENG_5 ?
Yep its fixed now I know, I was saying its the only time I have ever had a problem, the problem no longer exists now tho. Chris On Thu, 20 Jan 2005 08:56:33 -0800 (PST), John Polstra [EMAIL PROTECTED] wrote: On 18-Jan-2005 Chris wrote: I have been compiling ports using -O2 since I started using FreeBSD back in 2003 and only port that has had issues with this is lang/ezm3 in FreeBSD 5.2.1 it needed -O. I fixed that at the beginning of November. John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Higher ATA-Mode - lower speed
Am Donnerstag, 20. Januar 2005 19:48 schrieb Emanuel Strobl: Dear ata interested guys, I observed a strange behaviour which seems to explain my often noticed 16MB/s hard-limit I have a UDMA133 drive (MAXTOR 6L060J3) which saturates at 16MB/s when I dump anything to it, regardless of the block size. This transfer rate is reached with bs=4k and doesn't increase any more even not with bs=64k. Now, when I set the mode to UDMA100 I get well over 40MB/s Can anybody confirm that for different hw? Especially people like fandino who already discussed poor ata performance on -current (~16 Oct. 04). I can confirm that for my workstation here. i815 chipset and seagate ST380011A. When set to UDMA100 (the maximum) the following dump gives 16MB/s 'dd if=/dev/zero of=/usr/testfile bs=16k count=2000). When I limit the mode to UDMA66 I get 53MB/s It seems that's independent of UDMA133 instead it's when mode is set to the maximum the chipset can handle! This really hurts! But it's _the_ eplanation for all the poor ata performance reports. -Harry Why does UDMA133 mode limit the transfer speed so badly? And why do I get significantly slower transfer rates (32MB/s insted of 42MB/s) when I set the mode to UDMA66 (compared to UDMA100 but twice the speed of UDMA133)? There's only one device on the channel, so UDMA66 should be fine for 42MB/s. The controller is a HPT372. Best regards, -Harry pgpIwacfZHDtf.pgp Description: PGP signature
Re: Higher ATA-Mode - lower speed
Am Donnerstag, 20. Januar 2005 20:00 schrieb Emanuel Strobl: Am Donnerstag, 20. Januar 2005 19:48 schrieb Emanuel Strobl: Dear ata interested guys, I observed a strange behaviour which seems to explain my often noticed 16MB/s hard-limit I have a UDMA133 drive (MAXTOR 6L060J3) which saturates at 16MB/s when I dump anything to it, regardless of the block size. This transfer rate is reached with bs=4k and doesn't increase any more even not with bs=64k. Now, when I set the mode to UDMA100 I get well over 40MB/s Can anybody confirm that for different hw? Especially people like fandino who already discussed poor ata performance on -current (~16 Oct. 04). I can confirm that for my workstation here. i815 chipset and seagate ST380011A. When set to UDMA100 (the maximum) the following dump gives 16MB/s 'dd if=/dev/zero of=/usr/testfile bs=16k count=2000). When I limit the mode to UDMA66 I get 53MB/s Sorry, that's not 100% correct. After booting the machine I get 16MB/s. That's the hard limit. The disk is shown to operate with UDMA100 (that's the highest mode of the chipset). Now when I issue a 'atacontrol mode 0 udma100 udma100' (set the same mode as it's said to be) I get 57MB/s! From this point it doesn't matter what mode I set, the 16MB/s hard-limit vanished :)) But the original described problem of the 16MB/s hard-limit with udma133 is reproducable, means if I return mode to udma133 I see the 16MB/s limit again! -Harry It seems that's independent of UDMA133 instead it's when mode is set to the maximum the chipset can handle! This really hurts! But it's _the_ eplanation for all the poor ata performance reports. -Harry Why does UDMA133 mode limit the transfer speed so badly? And why do I get significantly slower transfer rates (32MB/s insted of 42MB/s) when I set the mode to UDMA66 (compared to UDMA100 but twice the speed of UDMA133)? There's only one device on the channel, so UDMA66 should be fine for 42MB/s. The controller is a HPT372. Best regards, -Harry pgpO7XoWwdhQx.pgp Description: PGP signature
Re: CFLAGS=-O2 -pipe problems in RELENG_5 ?
what does -fno-strict-alias do? I cannot find it in man gcc Chris On Thu, 20 Jan 2005 18:54:05 +, Chris [EMAIL PROTECTED] wrote: Yep its fixed now I know, I was saying its the only time I have ever had a problem, the problem no longer exists now tho. Chris On Thu, 20 Jan 2005 08:56:33 -0800 (PST), John Polstra [EMAIL PROTECTED] wrote: On 18-Jan-2005 Chris wrote: I have been compiling ports using -O2 since I started using FreeBSD back in 2003 and only port that has had issues with this is lang/ezm3 in FreeBSD 5.2.1 it needed -O. I fixed that at the beginning of November. John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Higher ATA-Mode - lower speed
Hello, On Thu, Jan 20, 2005 at 08:00:39PM +0100 or thereabouts, Emanuel Strobl wrote: I observed a strange behaviour which seems to explain my often noticed 16MB/s hard-limit I have a UDMA133 drive (MAXTOR 6L060J3) which saturates at 16MB/s when I dump anything to it, regardless of the block size. This transfer rate is reached with bs=4k and doesn't increase any more even not with bs=64k. Can anybody confirm that for different hw? Especially people like fandino who already discussed poor ata performance on -current (~16 Oct. 04). my tests shows speeds ranging from 36.9MB/s up to 59.3MB/s. System is 6.0-CURRENT (yup I know this is -stable list), built on Jan 10, 2005 with VIA 8235 UDMA133 controller. Disk configuration is as following: ad0: 38172MB MAXTOR 6L040J2/AR1.0400 [77557/16/63] at ata0-master UDMA133 ad1: 39205MB Maxtor 2F040J0/VAM51JJ0 [79656/16/63] at ata0-slave UDMA133 /usr is located on /dev/ad0s1e, and /various is located on /dev/ad1s1d. Testing of ad0: pleiades# dd if=/dev/zero of=/usr/testfile bs=4k count=2000 8192000 bytes transferred in 0.161283 secs (50792701 bytes/sec) pleiades# dd if=/dev/zero of=/usr/testfile bs=16k count=2000 32768000 bytes transferred in 0.792992 secs (41321975 bytes/sec) pleiades# dd if=/dev/zero of=/usr/testfile bs=64k count=2000 131072000 bytes transferred in 3.386982 secs (38698759 bytes/sec) Testing for ad1: pleiades# dd if=/dev/zero of=/various/testfile bs=4k count=2000 8192000 bytes transferred in 0.131618 secs (62240716 bytes/sec) pleiades# dd if=/dev/zero of=/various/testfile bs=16k count=2000 32768000 bytes transferred in 0.674646 secs (48570665 bytes/sec) pleiades# dd if=/dev/zero of=/various/testfile bs=64k count=2000 131072000 bytes transferred in 3.184140 secs (41164020 bytes/sec) I also run these tests on another machine shows speeds ranging from 49MB/s up to 63MB/s. System is 5.3-STABLE built on Dec 7, 2004 with SiS 735 UDMA100 controller. Disk configuration is as following: ad0: 76319MB WDC WD800JB-00ETA0/77.07W77 [155061/16/63] at ata0-master UDMA100 /usr is located on /dev/ad0s1e. Testing of ad0: amber# dd if=/dev/zero of=/usr/testfile bs=4k count=2000 8192000 bytes transferred in 0.154835 secs (52907939 bytes/sec) amber# dd if=/dev/zero of=/usr/testfile bs=16k count=2000 32768000 bytes transferred in 0.495422 secs (66141576 bytes/sec) amber# dd if=/dev/zero of=/usr/testfile bs=64k count=2000 131072000 bytes transferred in 2.546718 secs (51467023 bytes/sec) I hope that this information will help you. Cheers, Martin -- martin hudec * 421 907 303 393 * [EMAIL PROTECTED] * http://www.aeternal.net Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws. Douglas Adams, The Hitchhiker's Guide to the Galaxy pgpO0PNJjnuUp.pgp Description: PGP signature
Re: Very large directory
Hello Phillip, I've received a couple perl scripts from a few different people. I can't use any of them until this evening due to the current load of the machines though. Last night I ended up doing a strings on the directory, and taking its output into a for loop removing the files. if you have a bit of time to spare, take a look at the xargs(1) manpage. Using xargs instead of a for loop would have saved you a lot of time and system load (and a little bit of typing :-) Wolfgang ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unkillable OpenOffice.org process in 5.3p2
On Sun, 16 Jan 2005 18:14:33 +0100 Zsolt Kti [EMAIL PROTECTED] wrote: On Sat, 15 Jan 2005 13:23:44 -0800 Jeffrey Williams [EMAIL PROTECTED] wrote: [...] wondering if it is a problem with the interaction between the OO and java, or OO the pdf libraries, or a some shared library that facilitates the interaction between these components. I am afraid I I extensively use Java applications (jEdit, DBVisualizer, jCVS, Java Web Start and apps launched by JWS). I am going to try to experiment with all these in mind on Monday (at work). Since I have been avoiding java apps when workin with OO, I don't experience any problems! Bye Zsolt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Very large directory
Yeah - I thought of that after the for loop had already been in the process of starting for an hour. I figured I wasn't going to worry about it, and just head to bed at that point. If I wasn't drunk at the time (I'll pretend thats my excuse) I might have done a strings .| xargs instead of the shell script. Oh well. I can't really wo -Original Message- From: Wolfgang Zenker [mailto:[EMAIL PROTECTED] Sent: January 20, 2005 2:04 PM To: Phillip Salzman Cc: 'Peter Jeremy'; [EMAIL PROTECTED] Subject: Re: Very large directory Hello Phillip, I've received a couple perl scripts from a few different people. I can't use any of them until this evening due to the current load of the machines though. Last night I ended up doing a strings on the directory, and taking its output into a for loop removing the files. if you have a bit of time to spare, take a look at the xargs(1) manpage. Using xargs instead of a for loop would have saved you a lot of time and system load (and a little bit of typing :-) Wolfgang ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad disk or kernel (ATA Driver) problem? - SOLVED
On Wed, Jan 19, 2005 at 09:36:05PM -0600, Karl Denninger wrote: What 'other vendor' have you found that makes RELIABLE SATA disks in the high capacity (e.g. 200-300gb) arena? WD now makes a SATA RAID line. HIGHLY recommended by 3ware. /\/\ \/\/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFLAGS=-O2 -pipe problems in RELENG_5 ?
On Thu, 2005-01-20 at 19:17 +, Chris wrote: what does -fno-strict-alias do? I cannot find it in man gcc It is a truncation of -fno-strict-aliasing. The flag does not appear to be described in the gcc man page, but is documented in the gcc info page (search for -fstrict-aliasing). To quote the info page, -fstrict-aliasing allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. ... Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Very large directory
Oliver Fromme [EMAIL PROTECTED] wrote: I would suggest trying this simple hack: cd /var/spool/directory ; cat . | strings | xargs rm -f Since the original poster was willing to use -rf, wouldn't it be better to do: cd /var/spool/directory ; find . -type f -print0 | xargs -0 rm -f Slightly more typing, but more robust. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Disabling write-behind on IDE drives, and SMART
Question one: how do I disable write caching on IDE drives? I know the setting is hw.ata.wc=0, but where do I put that? In loader.conf? This is FreeBSD 4.10, btw. Also, has any thought been given to making the default 0, like it is for SCSI devices? I'm honestly surprised and disappointed that the default is speed over data integrity. Question two: is there any support for SMART in FreeBSD? I see that atacontrol cap displays the status (supported and disabled), but I don't know of any way to turn it on. Likewise, what about the other options shown by atacontrol cap? -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFLAGS=-O2 -pipe problems in RELENG_5 ?
Paul Mather said: On Thu, 2005-01-20 at 19:17 +, Chris wrote: what does -fno-strict-alias do? I cannot find it in man gcc It is a truncation of -fno-strict-aliasing. The flag does not appear to be described in the gcc man page, but is documented in the gcc info page (search for -fstrict-aliasing). To quote the info page, -fstrict-aliasing allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. ... Wouldn't we want strict aliasing then? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 4.11-RC3 available
It has been decided to provide two disc1 ISO images, one with the KDE windowing system packages on it and the other with the GNOME windowing system packages. They are named disc1-kde and disc1-gnome respectively. Other than which major windowing system is on them they are identical. It might be useful to put xpdf-3.00_5.tgz with dependencies on disc1-gnome too or even gpdf it is possible. Regards Bjrn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Disabling write-behind on IDE drives, and SMART
At 04:39 PM 20/01/2005, Jim C. Nasby wrote: Question one: how do I disable write caching on IDE drives? I know the setting is hw.ata.wc=0, but where do I put that? In loader.conf? This is FreeBSD 4.10, btw. Yes, you can put it in there. Also, has any thought been given to making the default 0, like it is for SCSI devices? I'm honestly surprised and disappointed that the default is speed over data integrity. It has been discussed quite a bit before and for a number of reasons, the default on was chosen. (google if you want to see the various reasons) Question two: is there any support for SMART in FreeBSD? RELENG_5 with /usr/ports/sysutils/smartmontools/ works really well. But you need to move to RELENG_5. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFLAGS=-O2 -pipe problems in RELENG_5 ?
On Thu, 2005-01-20 at 16:44 -0500, Mike Jakubik wrote: Paul Mather said: On Thu, 2005-01-20 at 19:17 +, Chris wrote: what does -fno-strict-alias do? I cannot find it in man gcc It is a truncation of -fno-strict-aliasing. The flag does not appear to be described in the gcc man page, but is documented in the gcc info page (search for -fstrict-aliasing). To quote the info page, -fstrict-aliasing allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. ... Wouldn't we want strict aliasing then? Yes, but unfortunately some ports circumvent the strict aliasing rules, which is why those ports break when building with -O2 (which causes -fstrict-aliasing to be enabled). Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: twa breakage on AMD64 with9.1.5.23wareversionand2005-01-1103:00:49 UTC RELENG_5 commit
Well, it may work for you, but not for me. Still hangs exactly in the same spot. Jean-Yves On 21/01/2005, at 12:24 AM, Michael Meltzer wrote: looks like patch3 worked, good job! I had to turn off TWA_DEBUG to get the boot going, the debug was starving the boot on a 9600 baud terminal. I can increase the speed and caputer the output on monday if it will help(it on the large side, bigger than the 10,000 line capture buffer in am using). I incude 2 iozone reports, the first one the new driver the second one the old driver, Is thier a way to increase the read ahead in freebsd?? -mjm --- Jean-Yves Avenard Hydrix Pty Ltd - Embedding the net www.hydrix.com | fax +61 3 9572 2686 | phone +61 3 9572 0686 ext 100 VoIP: direct: [EMAIL PROTECTED], general: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad disk or kernel (ATA Driver) problem?
On Thu, Jan 20, 2005 at 11:55:24AM -0500, Mike Tancsa wrote: At 04:13 PM 19/01/2005, Karl Denninger wrote: I'm having a lot of trouble believing this is an actual disk problem. Among other things, its happening at different places - not always at the same block. If you have the drives on a RELENG_5 box, try /usr/ports/sysutils/smartmontools/ Its quite handy to sort of various drive issues as well as to monitor for ongoing errors via the daemon. ---Mike Very cool - didn't know that was there. That's one very useful tool! -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad disk or kernel (ATA Driver) problem? - SOLVED
On Thu, Jan 20, 2005 at 08:17:40AM -0800, Darryl Okahata wrote: Karl Denninger [EMAIL PROTECTED] wrote: These two are DiamondMax10s - let's hope that this doesn't apply to that line as well. Out of curiosity, why didn't you consider Seagate ? The recent Maxtors that I have, if run 24x7, seem to die just after the warranty expires (for me, just over a year). I'm now switching back to Seagate, as they now have a nice 5-year warranty, but I don't have much experience with these new drives. The Maxtors I'm getting have 3-year warranties. Seagate's have been getting very poor performance reviews of late. of course a drive that pukes is worse than one that is slow! -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad disk or kernel (ATA Driver) problem? - SOLVED
Karl Denninger [EMAIL PROTECTED] wrote: Seagate's have been getting very poor performance reviews of late. Do you have any URLs? While I haven't been following disk drives closely, I haven't seen anything that points at very poor performance (average/boring performance, yes, but nothing really bad). Thanks. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Higher ATA-Mode - lower speed
martin hudec wrote: amber# dd if=/dev/zero of=/usr/testfile bs=64k count=2000 131072000 bytes transferred in 2.546718 secs (51467023 bytes/sec) These are not very usefull tests of raw disk bandwith because they use the filesystem (and are hence subject to the vagiaries of block allocation, etc) and are not likely to be very repeatable or comparable. Nore are the big enough or long enough to reduce the variance of the result or cover one-off spikes (e.g. what if it is running just when a cron job happens to kick off?) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Very large directory
Darryl Okahata wrote: find . -type f -print0 | xargs -0 rm -f Slightly more typing, but more robust. The find utility of FreeBSD knows a -delete option, e.g.: find /path/to/your/directory -type f -delete Regards Bjrn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Persisting troubles with periodic stalls every few minutes
top -qbSs 1 -d max /var/tmp/somefile Thank you, that helped. Although top did not tell me which process was guilty directly, it allowed me to track it down. For the record: The process hogging the entire CPU was Xorg, which in turn was being pushed by the KDE World Clock. At my screen resolution, the clock redraws itself every 45 minutes. Apparently, it does this in a very inefficient way, using a lot of CPU and making heavy use of the disk drive. I have filed a bug report on this with KDE: http://bugs.kde.org/show_bug.cgi?id=97565 Thanks Gavin and Kris for your input, - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: twa breakage onAMD64with9.1.5.23wareversionand2005-01-1103:00:49 UTC RELENG_5 commit
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michael Meltzer Sent: Thursday, January 20, 2005 5:25 AM To: Vinod Kashyap Cc: freebsd stable Subject: Re: twa breakage on AMD64with9.1.5.23wareversionand2005-01-1103:00:49 UTC RELENG_5 commit looks like patch3 worked, good job! I had to turn off TWA_DEBUG to get the boot going, the debug was starving the boot on a 9600 baud terminal. I can increase the speed and caputer the output on monday if it will help(it on the large side, bigger than the 10,000 line capture buffer in Don't worry about capturing all the output... am using). I incude 2 iozone reports, the first one the new driver the second one the old driver, Is thier a way to increase the read ahead in freebsd?? -mjm Setting sysctl vfs.read_max to about 512 helps in sequential reads. iozone -s 20480m -r 60 -i 0 -i 1 -t 1 Iozone: Performance Test of File I/O Version $Revision: 3.196 $ Compiled for 64 bit mode. Build: freebsd Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Jean-Marc Zucconi, Jeff Blomberg. Run began: Thu Jan 20 07:45:52 2005 File size set to 20971520 KB Record Size 60 KB Command line used: iozone -s 20480m -r 60 -i 0 -i 1 -t 1 Output is in Kbytes/sec Time Resolution = 0.01 seconds. Processor cache size set to 1024 Kbytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. Throughput test with 1 process Each process writes a 20971520 Kbyte file in 60 Kbyte records Children see throughput for 1 initial writers = 78219.47 KB/sec Parent sees throughput for 1 initial writers = 78060.45 KB/sec Min throughput per process = 78219.47 KB/sec Max throughput per process = 78219.47 KB/sec Avg throughput per process = 78219.47 KB/sec Min xfer= 20971500.00 KB Children see throughput for 1 rewriters= 19394.53 KB/sec Parent sees throughput for 1 rewriters = 19394.32 KB/sec Min throughput per process = 19394.53 KB/sec Max throughput per process = 19394.53 KB/sec Avg throughput per process = 19394.53 KB/sec Min xfer= 20971500.00 KB Children see throughput for 1 readers = 55960.09 KB/sec Parent sees throughput for 1 readers = 55954.25 KB/sec Min throughput per process = 55960.09 KB/sec Max throughput per process = 55960.09 KB/sec Avg throughput per process = 55960.09 KB/sec Min xfer= 20971500.00 KB Children see throughput for 1 re-readers= 55948.26 KB/sec Parent sees throughput for 1 re-readers = 55946.60 KB/sec Min throughput per process = 55948.26 KB/sec Max throughput per process = 55948.26 KB/sec Avg throughput per process = 55948.26 KB/sec Min xfer= 20971500.00 KB iozone test complete. iozone -s 20480m -r 60 -i 0 -i 1 -t 1 Iozone: Performance Test of File I/O Version $Revision: 3.196 $ Compiled for 64 bit mode. Build: freebsd Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Jean-Marc Zucconi, Jeff Blomberg. Run began: Mon Dec 20 21:03:36 2004 File size set to 20971520 KB Record Size 60 KB Command line used: iozone -s 20480m -r 60 -i 0 -i 1 -t 1 Output is in Kbytes/sec Time Resolution = 0.01 seconds. Processor cache size set to 1024 Kbytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. Throughput test with 1 process Each process writes a 20971520 Kbyte file in 60 Kbyte records Children see throughput for 1 initial writers = 78738.67
Re: User's cron job creates zombie process on 5.3
On 20 Jan, spam maps wrote:
Peter Jeremy wrote:
My guess is that your ssh process is holding open
file descriptors and the cron child process is
waiting for these descriptors to close before
wait()ing for the child. If this is true, then you
should avoid it with something like:
( /usr/bin/ssh -n -f ${tunnel} /dev/null 21 )
I suspect that the to put ssh in the background isn't necessary.
BINGO!
That works. Zombie has gone. Thank you.
Leaving a zombie process around, means there's a
kind
of bug/mistake somewhere, right?
Yes. But it's not necessarily a bug in FreeBSD :-).
So, after you've given me a complicated solution to
avoid the zombie, can you tell which program is at
error here? Cron, ssh, or FreeBSD?
Maybe none of the above. I suspect that cron is waiting for stdout
and/or stderr from the cron job to close before it reaps the child. The
reason is that cron wants to consume any output of the cron job, and if
the cron job writes to stdout or stderr, cron will mail it to the owner
of the job. The ssh -f flag is what is causing the problem, normally
stdout and stderr get closed when the top level process of a cron job
exits.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
secure level 2 unable to modify pf rules
Hello, The manual page for securelevel says that secure level 3 provides the same functionality as secure level 2 plus the protection of pf/ipf/ipfw against modification. Since pf/ipf/ipfw protection is an addition, I assume that it should not be present with secure level 2. For some reason that's not the reality. gater# id uid=0(root) gid=0(wheel) groups=0(wheel), 5(operator) gater# uname -rs FreeBSD 5.3-RELEASE-p5 gater# sysctl kern.securelevel kern.securelevel: 2 gater# pfctl -F all pfctl: pfctl_clear_rules: Operation not permitted gater# Is there a bug in the documentation or in the implementation of secure level? Or perhaps, did I misinterpret something? Thanks in advance, Andrew pgpCVO8QBtsBz.pgp Description: PGP signature
/libexec/ld-elf.so.1: /lib/libc.so.5: Unsupported relocation type 136 in non-PLT relocations
Hi all, I have been getting this all day today. I have no idea what caused it or how to fix it. Has anyone got a clue? Google doesn't seem too know much about it... /libexec/ld-elf.so.1: /lib/libc.so.5: Unsupported relocation type 136 in non-PLT relocations ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Very large directory
On Thu, 2005-Jan-20 13:36:30 -0800, Darryl Okahata wrote: Since the original poster was willing to use -rf, wouldn't it be better to do: cd /var/spool/directory ; find . -type f -print0 | xargs -0 rm -f The original poster mentioned that find wouldn't work: find(1) uses fts(3) which reads the entire directory into memory. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: User's cron job creates zombie process on 5.3
--- Don Lewis [EMAIL PROTECTED] wrote:
On 20 Jan, spam maps wrote:
Peter Jeremy wrote:
My guess is that your ssh process is holding open
file descriptors and the cron child process is
waiting for these descriptors to close before
wait()ing for the child. If this is true, then
you
should avoid it with something like:
( /usr/bin/ssh -n -f ${tunnel} /dev/null 21
)
I suspect that the to put ssh in the background
isn't necessary.
You're right indeed, it also works without the .
Thanks,
Rob.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure level 2 unable to modify pf rules
On Thu, Jan 20, 2005 at 07:32:01PM -0800, Andrew Konstantinov wrote:
Hello,
The manual page for securelevel says that secure level 3 provides the same
functionality as secure level 2 plus the protection of pf/ipf/ipfw against
modification. Since pf/ipf/ipfw protection is an addition, I assume that it
should not be present with secure level 2. For some reason that's not the
reality.
gater# id
uid=0(root) gid=0(wheel) groups=0(wheel), 5(operator)
gater# uname -rs
FreeBSD 5.3-RELEASE-p5
gater# sysctl kern.securelevel
kern.securelevel: 2
gater# pfctl -F all
pfctl: pfctl_clear_rules: Operation not permitted
gater#
Is there a bug in the documentation or in the implementation of secure level?
Or perhaps, did I misinterpret something?
Replying to myself. This should fix the bug if it's really a bug and not a
feature.
--- sys/contrib/pf/net/pf_ioctl.c.orig Thu Jan 20 22:40:35 2005
+++ sys/contrib/pf/net/pf_ioctl.c Thu Jan 20 22:41:24 2005
@@ -1058,9 +1058,9 @@
/* XXX keep in sync with switch() below */
#ifdef __FreeBSD__
- if (securelevel_gt(td-td_ucred, 1))
+ if (securelevel_gt(td-td_ucred, 2))
#else
- if (securelevel 1)
+ if (securelevel 2)
#endif
switch (cmd) {
case DIOCGETRULES:
pgpRduUW5OF0x.pgp
Description: PGP signature
Re: Disabling write-behind on IDE drives, and SMART
Jim C. Nasby wrote: Question one: how do I disable write caching on IDE drives? I know the setting is hw.ata.wc=0, but where do I put that? In loader.conf? This is FreeBSD 4.10, btw. In /boot/loader.conf will do it. Also, has any thought been given to making the default 0, like it is for SCSI devices? I'm honestly surprised and disappointed that the default is speed over data integrity. I think it was trialled in 4.3 then changed for 4.4 (according to the handbook, the performance hit was considered to be too high) best wishes Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
