How to stop attached USB device / send IRP_MN_REMOVE_DEVICE?
Hi all, Is there a tool under FreeBSD 6.2 that properly stops a USB device, equivalent to Windows XPs Safely Remove Hardware? I noticed that Windows sends a IRP_MN_REMOVE_DEVICE command, after which my LaCie external HDD spins down. Same applies to any USB stick: the light goes out on the stick. I would like to do this under FreeBSD too. camcontrol eject or stop don't do anything. So, the question really is: how to send a IRP_MN_REMOVE_DEVICE command? Thanks, Sven ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to stop attached USB device / send IRP_MN_REMOVE_DEVICE?
Is there a tool under FreeBSD 6.2 that properly stops a USB device, equivalent to Windows XPs Safely Remove Hardware? I noticed that Windows sends a IRP_MN_REMOVE_DEVICE command, after which my LaCie external HDD spins down. Same applies to any USB stick: the light goes out on the stick. I would like to do this under FreeBSD too. camcontrol eject or stop don't do anything. So, the question really is: how to send a IRP_MN_REMOVE_DEVICE command? `camcontrol da? stop` seemed to do the trick before (5.2.1-R, AFAIR), but now I'm not sure (looks like it doesn't) tested with SCSI hard drives and Adaptec 29160 Sven [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to stop attached USB device / send IRP_MN_REMOVE_DEVICE?
On Tue, 14 Aug 2007 03:08:33 -0700 [EMAIL PROTECTED] wrote: Is there a tool under FreeBSD 6.2 that properly stops a USB device, equivalent to Windows XPs Safely Remove Hardware? I noticed that Windows sends a IRP_MN_REMOVE_DEVICE command, after which my LaCie external HDD spins down. Same applies to any USB stick: the light goes out on the stick. I would like to do this under FreeBSD too. camcontrol eject or stop don't do anything. So, the question really is: how to send a IRP_MN_REMOVE_DEVICE command? `camcontrol da? stop` seemed to do the trick before (5.2.1-R, AFAIR), but now I'm not sure (looks like it doesn't) sorry, I meant to say that `camcontrol da? stop` does not power down the device anymore; nonetheless, it is probably safe to disconnect it tested with SCSI hard drives and Adaptec 29160 Sven [SorAlx] ridin' VS1400 [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to stop attached USB device / send IRP_MN_REMOVE_DEVICE?
So, the question really is: how to send a IRP_MN_REMOVE_DEVICE command? `camcontrol da? stop` seemed to do the trick before (5.2.1-R, AFAIR), but now I'm not sure (looks like it doesn't) sorry, I meant to say that `camcontrol da? stop` does not power down the device anymore; nonetheless, it is probably safe to disconnect it No, camcontrol does not support this over USB. Windows XP demonstrates it is technically possible, and I do not believe it is fully safe to disconnect the drive (even when unmounted), as the drive then is not able to park its heads, which it DOES do under XP. So, we come back to the original question: how to send an IRP_MN_REMOVE_DEVICE event? Regards, Sven ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to stop attached USB device / send IRP_MN_REMOVE_DEVICE?
Sven Hazejager wrote: So, the question really is: how to send a IRP_MN_REMOVE_DEVICE command? `camcontrol da? stop` seemed to do the trick before (5.2.1-R, AFAIR), but now I'm not sure (looks like it doesn't) sorry, I meant to say that `camcontrol da? stop` does not power down the device anymore; nonetheless, it is probably safe to disconnect it No, camcontrol does not support this over USB. Windows XP demonstrates it is technically possible, and I do not believe it is fully safe to disconnect the drive (even when unmounted), as the drive then is not able to park its heads, which it DOES do under XP. So, we come back to the original question: how to send an IRP_MN_REMOVE_DEVICE event? Maybe this helps? man camcontrol ? : cmd Allows the user to send an arbitrary SCSI CDB to any device. The cmd function requires the -c argument to specify the CDB. Other arguments are optional, depending on the command type. The command and data specification syntax is documented in cam_cdbparse(3). NOTE: If the CDB specified causes data to be transfered to or from the SCSI device in question, you MUST specify either -i or -o. -c cmd [args] This specifies the SCSI CDB. CDBs may be 6, 10, 12 or 16 bytes. -i len fmt This specifies the amount of data to read, and how it should be displayed. If the format is `-', len bytes of data will be read from the device and written to stan- dard output. -o len fmt [args] This specifies the amount of data to be written to a device, and the data that is to be written. If the format is `-', len bytes of data will be read from standard input and written to the device. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to stop attached USB device / send IRP_MN_REMOVE_DEVICE?
On Tue, Aug 14, 2007 at 04:14:06PM +0200, Sven Hazejager wrote: So, the question really is: how to send a IRP_MN_REMOVE_DEVICE command? `camcontrol da? stop` seemed to do the trick before (5.2.1-R, AFAIR), but now I'm not sure (looks like it doesn't) sorry, I meant to say that `camcontrol da? stop` does not power down the device anymore; nonetheless, it is probably safe to disconnect it No, camcontrol does not support this over USB. Windows XP demonstrates it is technically possible, and I do not believe it is fully safe to disconnect the drive (even when unmounted), as the drive then is not able to park its heads, which it DOES do under XP. Why do you think it is not safe? You either don't physically move the drive when disconneting it or it's not a mechanical drive at all. So, we come back to the original question: how to send an IRP_MN_REMOVE_DEVICE event? You don't have to, there is nothing more than not using the device you are about to remove. This is different in windows where every device available is automatically mounted, polled for media change, or whatever. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to stop attached USB device / send IRP_MN_REMOVE_DEVICE?
Sven Hazejager wrote: No, camcontrol does not support this over USB. Windows XP demonstrates it is technically possible, and I do not believe it is fully safe to disconnect the drive (even when unmounted), as the drive then is not able to park its heads, which it DOES do under XP. Every hard disk parks its head when power is switched off. Last time I saw a hard disk which required a command to park its heads was about 20 years ago on a DOS machine. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] newsyslog - don't compress first log file
On Fri, Aug 10, 2007 at 02:19:55PM +0300, Artis Caune wrote: How about aditional flag (X) to newsyslog, which don't compress first log file? This is useful for apache. ... After a bit of discussion here, and using a patch to newsyslog.c supplied by Dirk GOUDERS [EMAIL PROTECTED] (which I tested), I've filed a PR with the patches which may be accessed at http://www.freebsd.org/cgi/query-pr.cgi?pr=115486. I encourage folks interested in the issue to follow up to the PR. I'm confident that the supplied patches (against newsyslog.c rev. 1.107) will address the above-cited issue. Peace, david -- David H. Wolfskill [EMAIL PROTECTED] Anything and everything is a (potential) cat toy. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpDqn7griE9p.pgp Description: PGP signature
memset bugs.
A grep I crafted to pick up on some common bugs happened upon
a copy of the FreeBSD CVS tree that I happened to have handy
and found the bugs below where the 2nd 3rd arguments to
memset calls have been swapped.
I'm unfamiliar with how patch submission works in FreeBSD,
but hopefully someone can eyeball this for correctness
and get it committed, or forward it on to the right people.
Thanks,
Dave
--- src/sys/netinet/sctp_output.c~ 2007-08-14 15:44:11.0 -0400
+++ src/sys/netinet/sctp_output.c 2007-08-14 15:44:27.0 -0400
@@ -6331,7 +6331,7 @@ out_gu:
rcv_flags |= SCTP_DATA_UNORDERED;
}
/* clear out the chunk before setting up */
- memset(chk, sizeof(*chk), 0);
+ memset(chk, 0, sizeof(*chk));
chk-rec.data.rcv_flags = rcv_flags;
if (SCTP_BUF_IS_EXTENDED(sp-data)) {
chk-copy_by_ref = 1;
--- src/usr.sbin/nscd/agents/services.c~2007-08-14 15:44:33.0
-0400
+++ src/usr.sbin/nscd/agents/services.c 2007-08-14 15:44:41.0 -0400
@@ -171,7 +171,7 @@ services_lookup_func(const char *key, si
if (size 0) {
proto = (char *)malloc(size + 1);
assert(proto != NULL);
- memset(proto, size + 1, 0);
+ memset(proto, 0, size + 1);
memcpy(proto, key + sizeof(enum nss_lookup_type) +
sizeof(int), size);
}
--- src/usr.sbin/cached/agents/services.c~ 2007-08-14 15:44:45.0
-0400
+++ src/usr.sbin/cached/agents/services.c 2007-08-14 15:44:52.0
-0400
@@ -171,7 +171,7 @@ services_lookup_func(const char *key, si
if (size 0) {
proto = (char *)malloc(size + 1);
assert(proto != NULL);
- memset(proto, size + 1, 0);
+ memset(proto, 0, size + 1);
memcpy(proto, key + sizeof(enum nss_lookup_type) +
sizeof(int), size);
}
--- src/contrib/gdb/gdb/std-regs.c~ 2007-08-14 15:44:56.0 -0400
+++ src/contrib/gdb/gdb/std-regs.c 2007-08-14 15:45:22.0 -0400
@@ -61,7 +61,7 @@ value_of_builtin_frame_reg (struct frame
val = allocate_value (builtin_type_frame_reg);
VALUE_LVAL (val) = not_lval;
buf = VALUE_CONTENTS_RAW (val);
- memset (buf, TYPE_LENGTH (VALUE_TYPE (val)), 0);
+ memset (buf, 0, TYPE_LENGTH (VALUE_TYPE (val)));
/* frame.base. */
if (frame != NULL)
ADDRESS_TO_POINTER (builtin_type_void_data_ptr, buf,
@@ -87,7 +87,7 @@ value_of_builtin_frame_fp_reg (struct fr
struct value *val = allocate_value (builtin_type_void_data_ptr);
char *buf = VALUE_CONTENTS_RAW (val);
if (frame == NULL)
- memset (buf, TYPE_LENGTH (VALUE_TYPE (val)), 0);
+ memset (buf, 0, TYPE_LENGTH (VALUE_TYPE (val)));
else
ADDRESS_TO_POINTER (builtin_type_void_data_ptr, buf,
get_frame_base_address (frame));
@@ -105,7 +105,7 @@ value_of_builtin_frame_pc_reg (struct fr
struct value *val = allocate_value (builtin_type_void_data_ptr);
char *buf = VALUE_CONTENTS_RAW (val);
if (frame == NULL)
- memset (buf, TYPE_LENGTH (VALUE_TYPE (val)), 0);
+ memset (buf, 0, TYPE_LENGTH (VALUE_TYPE (val)));
else
ADDRESS_TO_POINTER (builtin_type_void_data_ptr, buf,
get_frame_pc (frame));
--- src/contrib/gdb/gdb/remote.c~ 2007-08-14 15:45:25.0 -0400
+++ src/contrib/gdb/gdb/remote.c2007-08-14 15:45:37.0 -0400
@@ -3463,7 +3463,7 @@ remote_store_registers (int regnum)
{
int i;
regs = alloca (rs-sizeof_g_packet);
-memset (regs, rs-sizeof_g_packet, 0);
+memset (regs, 0, rs-sizeof_g_packet);
for (i = 0; i NUM_REGS + NUM_PSEUDO_REGS; i++)
{
struct packet_reg *r = rs-regs[i];
--
http://www.codemonkey.org.uk
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to stop attached USB device / send IRP_MN_REMOVE_DEVICE?
Sven Hazejager [EMAIL PROTECTED] writes: No, camcontrol does not support this over USB. Windows XP demonstrates it is technically possible, and I do not believe it is fully safe to disconnect the drive (even when unmounted), as the drive then is not able to park its heads, which it DOES do under XP. All modern disks (since at least the early 1990s) automatically park their heads when they lose power. There is no need to do it in software. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: memset bugs.
Dave Jones [EMAIL PROTECTED] writes:
A grep I crafted to pick up on some common bugs happened upon
a copy of the FreeBSD CVS tree that I happened to have handy
and found the bugs below where the 2nd 3rd arguments to
memset calls have been swapped.
[...]
--- src/sys/netinet/sctp_output.c~2007-08-14 15:44:11.0 -0400
+++ src/sys/netinet/sctp_output.c 2007-08-14 15:44:27.0 -0400
@@ -6331,7 +6331,7 @@ out_gu:
rcv_flags |= SCTP_DATA_UNORDERED;
}
/* clear out the chunk before setting up */
- memset(chk, sizeof(*chk), 0);
+ memset(chk, 0, sizeof(*chk));
chk-rec.data.rcv_flags = rcv_flags;
if (SCTP_BUF_IS_EXTENDED(sp-data)) {
chk-copy_by_ref = 1;
Pointy hat to [EMAIL PROTECTED]
--- src/usr.sbin/nscd/agents/services.c~ 2007-08-14 15:44:33.0
-0400
+++ src/usr.sbin/nscd/agents/services.c 2007-08-14 15:44:41.0
-0400
@@ -171,7 +171,7 @@ services_lookup_func(const char *key, si
if (size 0) {
proto = (char *)malloc(size + 1);
assert(proto != NULL);
- memset(proto, size + 1, 0);
+ memset(proto, 0, size + 1);
memcpy(proto, key + sizeof(enum nss_lookup_type) +
sizeof(int), size);
}
--- src/usr.sbin/cached/agents/services.c~2007-08-14 15:44:45.0
-0400
+++ src/usr.sbin/cached/agents/services.c 2007-08-14 15:44:52.0
-0400
@@ -171,7 +171,7 @@ services_lookup_func(const char *key, si
if (size 0) {
proto = (char *)malloc(size + 1);
assert(proto != NULL);
- memset(proto, size + 1, 0);
+ memset(proto, 0, size + 1);
memcpy(proto, key + sizeof(enum nss_lookup_type) +
sizeof(int), size);
}
These two are actually the same file - cached is in the process of being
renamed to nscd. Pointy hat to [EMAIL PROTECTED]
--- src/contrib/gdb/gdb/std-regs.c~ 2007-08-14 15:44:56.0 -0400
+++ src/contrib/gdb/gdb/std-regs.c2007-08-14 15:45:22.0 -0400
@@ -61,7 +61,7 @@ value_of_builtin_frame_reg (struct frame
val = allocate_value (builtin_type_frame_reg);
VALUE_LVAL (val) = not_lval;
buf = VALUE_CONTENTS_RAW (val);
- memset (buf, TYPE_LENGTH (VALUE_TYPE (val)), 0);
+ memset (buf, 0, TYPE_LENGTH (VALUE_TYPE (val)));
/* frame.base. */
if (frame != NULL)
ADDRESS_TO_POINTER (builtin_type_void_data_ptr, buf,
@@ -87,7 +87,7 @@ value_of_builtin_frame_fp_reg (struct fr
struct value *val = allocate_value (builtin_type_void_data_ptr);
char *buf = VALUE_CONTENTS_RAW (val);
if (frame == NULL)
- memset (buf, TYPE_LENGTH (VALUE_TYPE (val)), 0);
+ memset (buf, 0, TYPE_LENGTH (VALUE_TYPE (val)));
else
ADDRESS_TO_POINTER (builtin_type_void_data_ptr, buf,
get_frame_base_address (frame));
@@ -105,7 +105,7 @@ value_of_builtin_frame_pc_reg (struct fr
struct value *val = allocate_value (builtin_type_void_data_ptr);
char *buf = VALUE_CONTENTS_RAW (val);
if (frame == NULL)
- memset (buf, TYPE_LENGTH (VALUE_TYPE (val)), 0);
+ memset (buf, 0, TYPE_LENGTH (VALUE_TYPE (val)));
else
ADDRESS_TO_POINTER (builtin_type_void_data_ptr, buf,
get_frame_pc (frame));
--- src/contrib/gdb/gdb/remote.c~ 2007-08-14 15:45:25.0 -0400
+++ src/contrib/gdb/gdb/remote.c 2007-08-14 15:45:37.0 -0400
@@ -3463,7 +3463,7 @@ remote_store_registers (int regnum)
{
int i;
regs = alloca (rs-sizeof_g_packet);
-memset (regs, rs-sizeof_g_packet, 0);
+memset (regs, 0, rs-sizeof_g_packet);
for (i = 0; i NUM_REGS + NUM_PSEUDO_REGS; i++)
{
struct packet_reg *r = rs-regs[i];
These should go upstream to the gdb maintainers ([EMAIL PROTECTED]).
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: memset bugs.
Thanks for the pointer...
Julian and Sam also sent this to me on the SCTP side.
The local CVS repository on lakerest.net now has this fix
in it.. and others... I have added this to the queue to
go in to patchset 15.. (I am still waiting on re for patchset 14).
R
Dag-Erling Smørgrav wrote:
Dave Jones [EMAIL PROTECTED] writes:
A grep I crafted to pick up on some common bugs happened upon
a copy of the FreeBSD CVS tree that I happened to have handy
and found the bugs below where the 2nd 3rd arguments to
memset calls have been swapped.
[...]
--- src/sys/netinet/sctp_output.c~ 2007-08-14 15:44:11.0 -0400
+++ src/sys/netinet/sctp_output.c 2007-08-14 15:44:27.0 -0400
@@ -6331,7 +6331,7 @@ out_gu:
rcv_flags |= SCTP_DATA_UNORDERED;
}
/* clear out the chunk before setting up */
- memset(chk, sizeof(*chk), 0);
+ memset(chk, 0, sizeof(*chk));
chk-rec.data.rcv_flags = rcv_flags;
if (SCTP_BUF_IS_EXTENDED(sp-data)) {
chk-copy_by_ref = 1;
Pointy hat to [EMAIL PROTECTED]
--- src/usr.sbin/nscd/agents/services.c~2007-08-14 15:44:33.0
-0400
+++ src/usr.sbin/nscd/agents/services.c 2007-08-14 15:44:41.0 -0400
@@ -171,7 +171,7 @@ services_lookup_func(const char *key, si
if (size 0) {
proto = (char *)malloc(size + 1);
assert(proto != NULL);
- memset(proto, size + 1, 0);
+ memset(proto, 0, size + 1);
memcpy(proto, key + sizeof(enum nss_lookup_type) +
sizeof(int), size);
}
--- src/usr.sbin/cached/agents/services.c~ 2007-08-14 15:44:45.0
-0400
+++ src/usr.sbin/cached/agents/services.c 2007-08-14 15:44:52.0
-0400
@@ -171,7 +171,7 @@ services_lookup_func(const char *key, si
if (size 0) {
proto = (char *)malloc(size + 1);
assert(proto != NULL);
- memset(proto, size + 1, 0);
+ memset(proto, 0, size + 1);
memcpy(proto, key + sizeof(enum nss_lookup_type) +
sizeof(int), size);
}
These two are actually the same file - cached is in the process of being
renamed to nscd. Pointy hat to [EMAIL PROTECTED]
--- src/contrib/gdb/gdb/std-regs.c~ 2007-08-14 15:44:56.0 -0400
+++ src/contrib/gdb/gdb/std-regs.c 2007-08-14 15:45:22.0 -0400
@@ -61,7 +61,7 @@ value_of_builtin_frame_reg (struct frame
val = allocate_value (builtin_type_frame_reg);
VALUE_LVAL (val) = not_lval;
buf = VALUE_CONTENTS_RAW (val);
- memset (buf, TYPE_LENGTH (VALUE_TYPE (val)), 0);
+ memset (buf, 0, TYPE_LENGTH (VALUE_TYPE (val)));
/* frame.base. */
if (frame != NULL)
ADDRESS_TO_POINTER (builtin_type_void_data_ptr, buf,
@@ -87,7 +87,7 @@ value_of_builtin_frame_fp_reg (struct fr
struct value *val = allocate_value (builtin_type_void_data_ptr);
char *buf = VALUE_CONTENTS_RAW (val);
if (frame == NULL)
- memset (buf, TYPE_LENGTH (VALUE_TYPE (val)), 0);
+ memset (buf, 0, TYPE_LENGTH (VALUE_TYPE (val)));
else
ADDRESS_TO_POINTER (builtin_type_void_data_ptr, buf,
get_frame_base_address (frame));
@@ -105,7 +105,7 @@ value_of_builtin_frame_pc_reg (struct fr
struct value *val = allocate_value (builtin_type_void_data_ptr);
char *buf = VALUE_CONTENTS_RAW (val);
if (frame == NULL)
- memset (buf, TYPE_LENGTH (VALUE_TYPE (val)), 0);
+ memset (buf, 0, TYPE_LENGTH (VALUE_TYPE (val)));
else
ADDRESS_TO_POINTER (builtin_type_void_data_ptr, buf,
get_frame_pc (frame));
--- src/contrib/gdb/gdb/remote.c~ 2007-08-14 15:45:25.0 -0400
+++ src/contrib/gdb/gdb/remote.c2007-08-14 15:45:37.0 -0400
@@ -3463,7 +3463,7 @@ remote_store_registers (int regnum)
{
int i;
regs = alloca (rs-sizeof_g_packet);
-memset (regs, rs-sizeof_g_packet, 0);
+memset (regs, 0, rs-sizeof_g_packet);
for (i = 0; i NUM_REGS + NUM_PSEUDO_REGS; i++)
{
struct packet_reg *r = rs-regs[i];
These should go upstream to the gdb maintainers ([EMAIL PROTECTED]).
DES
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 or 803-317-4952 (cell)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: memset bugs.
On Tue, Aug 14, 2007 at 03:49:50PM -0400, Dave Jones wrote: I'm unfamiliar with how patch submission works in FreeBSD, but hopefully someone can eyeball this for correctness and get it committed, or forward it on to the right people. The way to make sure your patch doesn't just get lost in the mailing list noise is to send a Problem Report (PR). There's no guarantee that it will be handled promptly, however, as we have a large backlog (more people willing to report bugs than to do some of the dirty work :-/ Many of the developers are already stretched thin.) The documentation is available at http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/. If anything is unclear, you can email [EMAIL PROTECTED] and we'll try to clarify things. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
