freebsd-hackers Digest, Vol 364, Issue 2
freebsd-hac...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
or, via email, send a message with subject or body 'help' to
freebsd-hac...@freebsd.org
You can reach the person managing the list at
freebsd-ha...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-hackers digest..."
Today's Topics:
1. Re: How to slow down SATA to 1.5 GBit/s ? (Thomas Schmitt)
2. Re: [patch] small fix to stop gcc warning for
lib/libstand/assert.c (John Baldwin)
3. [RFC] DTrace SYSCALL provider (was Re: [RFC] Saving the
latest errno from syscalls.) (Jung-uk Kim)
4. Re: How to slow down SATA to 1.5 GBit/s ? (Juergen Lock)
5. Re: How to slow down SATA to 1.5 GBit/s ? (Juergen Lock)
6. Re: How to slow down SATA to 1.5 GBit/s ? (Juergen Lock)
7. Re: How to slow down SATA to 1.5 GBit/s ? (Thomas Schmitt)
8. Re: [patch] small fix to stop gcc warning for
lib/libstand/assert.c (Alexander Best)
9. Re: How to slow down SATA to 1.5 GBit/s ? (Alexander Motin)
10. Re: How to slow down SATA to 1.5 GBit/s ? (Alexander Motin)
11. Problem with Realtek NIC (Ivan Radovanovic)
12. flash drive crashes hald on amd64 (george+...@m5p.com)
13. Re: flash drive crashes hald on amd64 (george+...@m5p.com)
----------------------------------------------------------------------
Message: 1
Date: Mon, 15 Mar 2010 15:27:09 +0100
From: "Thomas Schmitt" <scdb...@gmx.net>
Subject: Re: How to slow down SATA to 1.5 GBit/s ?
To: freebsd...@freebsd.org
Message-ID: <1060857...@192.168.2.69>
Hi,
the switch to ahci was successful and it looks
quite good, overall.
But probably i found a bug. I could need advise
where and how to submit it.
A particular sequence of SCSI commands leads to
an elsewise harmless stall of the dialog between
libburn and drive.
To close and re-open the libcam connection before
this sequence is enough to circumvent the
problem. But this remedy is not desirable.
Long story:
------------------------------------------------
I did the switch to ahci. Now my disk is
ada and my eSATA attached burner is not acd1|cd1
but only cd0.
The IDE ROM works fine with the vanilla
configuration. It obviously staid under ata
control as acd0|cd1.
With the poor eSATA connection at 3000 GBit/s
i still get the stalls. But after killing the
writing process and about 4 minutes of waiting
i get my drive back in most cases.
Sometimes i have to do a power cycle on the drive
to get it back as /dev/cd0.
Still no reboot or panic. I begin to like ahci.
(I find no trace of power cycle or re-plugging
in dmesg.)
The speed setter in camcontrol seems not to work.
Writing still gets stuck after a few MB.
So i used the boot time option.
dmesg tells:
cd0 at ahcich4 bus 0 target 0 lun 0
cd0: <TSSTcorp CDDVDW SH-S223B SB02> Removable CD-ROM SCSI-0 device
cd0: 300.000MB/s transfers
I added to /boot/device.hints :
hint.ahcich.4.sata_rev="1"
After reboot, i see in dmesg:
cd0 at ahcich4 bus 0 target 0 lun 0
cd0: <TSSTcorp CDDVDW SH-S223B SB02> Removable CD-ROM SCSI-0 device
cd0: 150.000MB/s transfers
Now everything seems to work - except libburn.
Grrr.
Writing looks good. But it does not end.
It is stuck in
READ DISC INFORMATION
51 00 00 00 00 00 00 00 22 00
and waits for the reply of the drive.
This happens when the new media state shall be
inquired after burning was completed.
If i do
cam_close_device()
and re-open the drive, then the same command
sequence succeeds.
(But this is a very undesirable gesture at that
point of processing.)
The problem does not appear with USB (and did
not while the drive was built-in at SATA).
The drive is surely not to blame.
So now i could need advise about filing a bug
report.
------------------------------------------------
Have a nice day :)
Thomas
------------------------------
Message: 2
Date: Mon, 15 Mar 2010 11:32:18 -0400
From: John Baldwin <j...@freebsd.org>
Subject: Re: [patch] small fix to stop gcc warning for
lib/libstand/assert.c
To: freebsd...@freebsd.org
Cc: Alexander Best <alexb...@wwu.de>
Message-ID: <20100315113...@freebsd.org>
Content-Type: Text/Plain; charset="iso-8859-15"
On Saturday 13 March 2010 08:52:19 am Alexander Best wrote:
> hello,
>
> this patch fixes the following gcc warning:
>
> /usr/src/lib/libstand/assert.c:43: warning: implicit declaration of
> function 'exit'
>
> by using abort() instead of exit() (which is illegal anyway). looking at
> lib/libc/gen/assert.c abort() seems save to use instead of exit().
There is no abort() in libstand or any of the boot code. If you built a full
world with this change you should have gotten a link error for /boot/loader.
exit() is required by the boot code however (see sys/boot/common/panic.c).
The use of exit() instead of abort() here is on purpose. This is the fix I
would use. I would not add 'exit()' to <stand.h> as it is not an interface
that libstand provides, but one that it requires from the environment it is
linked with.
Index: assert.c
===================================================================
--- assert.c (revision 204953)
+++ assert.c (working copy)
@@ -31,6 +31,8 @@
#include "stand.h"
+void exit(int);
+
void
__assert(const char *func, const char *file, int line, const char
*expression)
{
@@ -40,5 +42,5 @@
else
printf("Assertion failed: (%s), function %s, file %s, line "
"%d.\n", expression, func, file, line);
- exit();
+ exit(1);
}
--
John Baldwin
------------------------------
Message: 3
Date: Mon, 15 Mar 2010 14:10:33 -0400
From: Jung-uk Kim <jk...@FreeBSD.org>
Subject: [RFC] DTrace SYSCALL provider (was Re: [RFC] Saving the
latest errno from syscalls.)
To: freebsd...@freebsd.org
Cc: Kostik Belousov <kost...@gmail.com>, Marcel Moolenaar
<xcl...@mac.com>
Message-ID: <20100315141...@FreeBSD.org>
Content-Type: text/plain; charset="iso-8859-1"
On Friday 12 March 2010 01:32 pm, Jung-uk Kim wrote:
> On Friday 12 March 2010 04:29 am, Kostik Belousov wrote:
> > On Thu, Mar 11, 2010 at 06:15:07PM -0500, Jung-uk Kim wrote:
> > > On Thursday 11 March 2010 04:55 pm, Marcel Moolenaar wrote:
> > > > On Mar 11, 2010, at 1:24 PM, Jung-uk Kim wrote:
> > > > > While I was debugging syscalls, I found a very useful field
> > > > > in struct thread, td_errno. It seems it was added for
> > > > > dtrace but it is only populated on amd64 and i386. Is the
> > > > > attached patch acceptable for maintainers of other
> > > > > platforms?
> > > >
> > > > Isn't it better to do it in cpu_set_syscall_retval()?
> > > > That way you catch all cases, plus you can save the
> > > > translated error as well...
> > >
> > > I just took amd64/i386 as an example and I was not sure whether
> > > it was meant to store translated error or not. Does anyone
> > > with DTrace internal knowledge answer the question?
> >
> > I do not know that much about DTrace, but it seems that setting
> > td_errno in cpu_set_syscall_retval() is too late. Dtrace has a
> > probe after the syscall return, and it is called right before
> > cpu_set_syscall_retval() can be reasonably called. The probe only
> > issued for syscall that goes into sysent.
>
> Ah, I can see that now. So, if/when we implement DTrace SYSCALL
> provider for other arches, this is the right place. :-)
I went ahead and implemented DTrace SYSCALL providers for non-x86
arches. It passes 'make universe' test but I don't know if it works.
Can maintainers of other arches test or review the attached patch?
Thanks!
Jung-uk Kim
-------------- next part --------------
Index: sys/arm/arm/trap.c
===================================================================
--- sys/arm/arm/trap.c (revision 205172)
+++ sys/arm/arm/trap.c (working copy)
@@ -122,7 +122,18 @@ __FBSDID("$FreeBSD$");
#include <sys/kdb.h>
#endif
+#ifdef KDTRACE_HOOKS
+#include <sys/dtrace_bsd.h>
+/*
+ * This is a hook which is initialised by the systrace module
+ * when it is loaded. This keeps the DTrace syscall provider
+ * implementation opaque.
+ */
+systrace_probe_func_t systrace_probe_func;
+#endif
+
+
void swi_handler(trapframe_t *);
void undefinedinstruction(trapframe_t *);
@@ -925,9 +936,36 @@ syscall(struct thread *td, trapframe_t *frame, u_i
td->td_retval[1] = 0;
STOPEVENT(p, S_SCE, callp->sy_narg);
PTRACESTOP_SC(p, td, S_PT_SCE);
+
+#ifdef KDTRACE_HOOKS
+ /*
+ * If the systrace module has registered it's probe
+ * callback and if there is a probe active for the
+ * syscall 'entry', process the probe.
+ */
+ if (systrace_probe_func != NULL && sa.callp->sy_entry != 0)
+ (*systrace_probe_func)(sa.callp->sy_entry, sa.code,
+ sa.callp, sa.args);
+#endif
+
AUDIT_SYSCALL_ENTER(code, td);
error = (*callp->sy_call)(td, args);
AUDIT_SYSCALL_EXIT(error, td);
+
+ /* Save the latest error return value. */
+ td->td_errno = error;
+
+#ifdef KDTRACE_HOOKS
+ /*
+ * If the systrace module has registered it's probe
+ * callback and if there is a probe active for the
+ * syscall 'return', process the probe.
+ */
+ if (systrace_probe_func != NULL && sa.callp->sy_return != 0)
+ (*systrace_probe_func)(sa.callp->sy_return, sa.code,
+ sa.callp, sa.args);
+#endif
+
KASSERT(td->td_ar == NULL,
("returning from syscall with td_ar set!"));
}
Index: sys/powerpc/booke/trap.c
===================================================================
--- sys/powerpc/booke/trap.c (revision 205172)
+++ sys/powerpc/booke/trap.c (working copy)
@@ -75,6 +75,17 @@ __FBSDID("$FreeBSD$");
#include <machine/trap.h>
#include <machine/spr.h>
+#ifdef KDTRACE_HOOKS
+#include <sys/dtrace_bsd.h>
+
+/*
+ * This is a hook which is initialised by the systrace module
+ * when it is loaded. This keeps the DTrace syscall provider
+ * implementation opaque.
+ */
+systrace_probe_func_t systrace_probe_func;
+#endif
+
#ifdef FPU_EMU
#include <powerpc/fpu/fpu_extern.h>
#endif
@@ -409,10 +420,35 @@ syscall(struct trapframe *frame)
PTRACESTOP_SC(p, td, S_PT_SCE);
+#ifdef KDTRACE_HOOKS
+ /*
+ * If the systrace module has registered it's probe
+ * callback and if there is a probe active for the
+ * syscall 'entry', process the probe.
+ */
+ if (systrace_probe_func != NULL && sa.callp->sy_entry != 0)
+ (*systrace_probe_func)(sa.callp->sy_entry, sa.code,
+ sa.callp, sa.args);
+#endif
+
AUDIT_SYSCALL_ENTER(code, td);
error = (*callp->sy_call)(td, params);
AUDIT_SYSCALL_EXIT(error, td);
+ /* Save the latest error return value. */
+ td->td_errno = error;
+
+#ifdef KDTRACE_HOOKS
+ /*
+ * If the systrace module has registered it's probe
+ * callback and if there is a probe active for the
+ * syscall 'return', process the probe.
+ */
+ if (systrace_probe_func != NULL && sa.callp->sy_return != 0)
+ (*systrace_probe_func)(sa.callp->sy_return, sa.code,
+ sa.callp, sa.args);
+#endif
+
CTR3(KTR_SYSC, "syscall: p=%s %s ret=%x", p->p_comm,
syscallnames[code], td->td_retval[0]);
}
Index: sys/powerpc/aim/trap.c
===================================================================
--- sys/powerpc/aim/trap.c (revision 205172)
+++ sys/powerpc/aim/trap.c (working copy)
@@ -77,6 +77,17 @@ __FBSDID("$FreeBSD$");
#include <machine/spr.h>
#include <machine/sr.h>
+#ifdef KDTRACE_HOOKS
+#include <sys/dtrace_bsd.h>
+
+/*
+ * This is a hook which is initialised by the systrace module
+ * when it is loaded. This keeps the DTrace syscall provider
+ * implementation opaque.
+ */
+systrace_probe_func_t systrace_probe_func;
+#endif
+
static void trap_fatal(struct trapframe *frame);
static void printtrap(u_int vector, struct trapframe *frame, int isfatal,
int user);
@@ -405,10 +416,35 @@ syscall(struct trapframe *frame)
PTRACESTOP_SC(p, td, S_PT_SCE);
+#ifdef KDTRACE_HOOKS
+ /*
+ * If the systrace module has registered it's probe
+ * callback and if there is a probe active for the
+ * syscall 'entry', process the probe.
+ */
+ if (systrace_probe_func != NULL && sa.callp->sy_entry != 0)
+ (*systrace_probe_func)(sa.callp->sy_entry, sa.code,
+ sa.callp, sa.args);
+#endif
+
AUDIT_SYSCALL_ENTER(code, td);
error = (*callp->sy_call)(td, params);
AUDIT_SYSCALL_EXIT(error, td);
+ /* Save the latest error return value. */
+ td->td_errno = error;
+
+#ifdef KDTRACE_HOOKS
+ /*
+ * If the systrace module has registered it's probe
+ * callback and if there is a probe active for the
+ * syscall 'return', process the probe.
+ */
+ if (systrace_probe_func != NULL && sa.callp->sy_return != 0)
+ (*systrace_probe_func)(sa.callp->sy_return, sa.code,
+ sa.callp, sa.args);
+#endif
+
CTR3(KTR_SYSC, "syscall: p=%s %s ret=%x", td->td_name,
syscallnames[code], td->td_retval[0]);
}
Index: sys/sparc64/sparc64/trap.c
===================================================================
--- sys/sparc64/sparc64/trap.c (revision 205172)
+++ sys/sparc64/sparc64/trap.c (working copy)
@@ -94,6 +94,17 @@ __FBSDID("$FreeBSD$");
#include <machine/tsb.h>
#include <machine/watch.h>
+#ifdef KDTRACE_HOOKS
+#include <sys/dtrace_bsd.h>
+
+/*
+ * This is a hook which is initialised by the systrace module
+ * when it is loaded. This keeps the DTrace syscall provider
+ * implementation opaque.
+ */
+systrace_probe_func_t systrace_probe_func;
+#endif
+
struct syscall_args {
u_long code;
struct sysent *callp;
@@ -648,10 +659,35 @@ syscall(struct trapframe *tf)
td->td_retval[1] = 0;
}
+#ifdef KDTRACE_HOOKS
+ /*
+ * If the systrace module has registered it's probe
+ * callback and if there is a probe active for the
+ * syscall 'entry', process the probe.
+ */
+ if (systrace_probe_func != NULL && sa.callp->sy_entry != 0)
+ (*systrace_probe_func)(sa.callp->sy_entry, sa.code,
+ sa.callp, sa.args);
+#endif
+
AUDIT_SYSCALL_ENTER(sa.code, td);
error = (*sa.callp->sy_call)(td, sa.argp);
AUDIT_SYSCALL_EXIT(error, td);
+ /* Save the latest error return value. */
+ td->td_errno = error;
+
+#ifdef KDTRACE_HOOKS
+ /*
+ * If the systrace module has registered it's probe
+ * callback and if there is a probe active for the
+ * syscall 'return', process the probe.
+ */
+ if (systrace_probe_func != NULL && sa.callp->sy_return != 0)
+ (*systrace_probe_func)(sa.callp->sy_return, sa.code,
+ sa.callp, sa.args);
+#endif
+
CTR5(KTR_SYSC, "syscall: p=%p error=%d %s return %#lx %#lx",
p, error, syscallnames[sa.code], td->td_retval[0],
td->td_retval[1]);
Index: sys/ia64/ia64/trap.c
===================================================================
--- sys/ia64/ia64/trap.c (revision 205172)
+++ sys/ia64/ia64/trap.c (working copy)
@@ -76,6 +76,17 @@ __FBSDID("$FreeBSD$");
#include <ia64/disasm/disasm.h>
+#ifdef KDTRACE_HOOKS
+#include <sys/dtrace_bsd.h>
+
+/*
+ * This is a hook which is initialised by the systrace module
+ * when it is loaded. This keeps the DTrace syscall provider
+ * implementation opaque.
+ */
+systrace_probe_func_t systrace_probe_func;
+#endif
+
static int print_usertrap = 0;
SYSCTL_INT(_machdep, OID_AUTO, print_usertrap,
CTLFLAG_RW, &print_usertrap, 0, "");
@@ -970,10 +981,35 @@ syscall(struct trapframe *tf)
PTRACESTOP_SC(p, td, S_PT_SCE);
+#ifdef KDTRACE_HOOKS
+ /*
+ * If the systrace module has registered it's probe
+ * callback and if there is a probe active for the
+ * syscall 'entry', process the probe.
+ */
+ if (systrace_probe_func != NULL && sa.callp->sy_entry != 0)
+ (*systrace_probe_func)(sa.callp->sy_entry, sa.code,
+ sa.callp, sa.args);
+#endif
+
AUDIT_SYSCALL_ENTER(code, td);
error = (*callp->sy_call)(td, args);
AUDIT_SYSCALL_EXIT(error, td);
+ /* Save the latest error return value. */
+ td->td_errno = error;
+
+#ifdef KDTRACE_HOOKS
+ /*
+ * If the systrace module has registered it's probe
+ * callback and if there is a probe active for the
+ * syscall 'return', process the probe.
+ */
+ if (systrace_probe_func != NULL && sa.callp->sy_return != 0)
+ (*systrace_probe_func)(sa.callp->sy_return, sa.code,
+ sa.callp, sa.args);
+#endif
+
cpu_set_syscall_retval(td, error);
td->td_syscalls++;
Index: sys/ia64/ia32/ia32_trap.c
===================================================================
--- sys/ia64/ia32/ia32_trap.c (revision 205172)
+++ sys/ia64/ia32/ia32_trap.c (working copy)
@@ -48,6 +48,17 @@ __FBSDID("$FreeBSD$");
#include <security/audit/audit.h>
+#ifdef KDTRACE_HOOKS
+#include <sys/dtrace_bsd.h>
+
+/*
+ * This is a hook which is initialised by the systrace module
+ * when it is loaded. This keeps the DTrace syscall provider
+ * implementation opaque.
+ */
+systrace_probe_func_t systrace_probe_func;
+#endif
+
extern char *syscallnames[];
static void
@@ -124,9 +135,34 @@ ia32_syscall(struct trapframe *tf)
PTRACESTOP_SC(p, td, S_PT_SCE);
+#ifdef KDTRACE_HOOKS
+ /*
+ * If the systrace module has registered it's probe
+ * callback and if there is a probe active for the
+ * syscall 'entry', process the probe.
+ */
+ if (systrace_probe_func != NULL && sa.callp->sy_entry != 0)
+ (*systrace_probe_func)(sa.callp->sy_entry, sa.code,
+ sa.callp, sa.args);
+#endif
+
AUDIT_SYSCALL_ENTER(code, td);
error = (*callp->sy_call)(td, args64);
AUDIT_SYSCALL_EXIT(error, td);
+
+ /* Save the latest error return value. */
+ td->td_errno = error;
+
+#ifdef KDTRACE_HOOKS
+ /*
+ * If the systrace module has registered it's probe
+ * callback and if there is a probe active for the
+ * syscall 'return', process the probe.
+ */
+ if (systrace_probe_func != NULL && sa.callp->sy_return != 0)
+ (*systrace_probe_func)(sa.callp->sy_return, sa.code,
+ sa.callp, sa.args);
+#endif
}
switch (error) {
Index: sys/sun4v/sun4v/trap.c
===================================================================
--- sys/sun4v/sun4v/trap.c (revision 205172)
+++ sys/sun4v/sun4v/trap.c (working copy)
@@ -96,6 +96,17 @@
#include <security/audit/audit.h>
+#ifdef KDTRACE_HOOKS
+#include <sys/dtrace_bsd.h>
+
+/*
+ * This is a hook which is initialised by the systrace module
+ * when it is loaded. This keeps the DTrace syscall provider
+ * implementation opaque.
+ */
+systrace_probe_func_t systrace_probe_func;
+#endif
+
void trap(struct trapframe *tf, int64_t type, uint64_t data);
void syscall(struct trapframe *tf);
@@ -662,10 +673,35 @@ syscall(struct trapframe *tf)
PTRACESTOP_SC(p, td, S_PT_SCE);
+#ifdef KDTRACE_HOOKS
+ /*
+ * If the systrace module has registered it's probe
+ * callback and if there is a probe active for the
+ * syscall 'entry', process the probe.
+ */
+ if (systrace_probe_func != NULL && sa.callp->sy_entry != 0)
+ (*systrace_probe_func)(sa.callp->sy_entry, sa.code,
+ sa.callp, sa.args);
+#endif
+
AUDIT_SYSCALL_ENTER(code, td);
error = (*callp->sy_call)(td, argp);
AUDIT_SYSCALL_EXIT(error, td);
+ /* Save the latest error return value. */
+ td->td_errno = error;
+
+#ifdef KDTRACE_HOOKS
+ /*
+ * If the systrace module has registered it's probe
+ * callback and if there is a probe active for the
+ * syscall 'return', process the probe.
+ */
+ if (systrace_probe_func != NULL && sa.callp->sy_return != 0)
+ (*systrace_probe_func)(sa.callp->sy_return, sa.code,
+ sa.callp, sa.args);
+#endif
+
CTR5(KTR_SYSC, "syscall: p=%p error=%d %s return %#lx %#lx ", p,
error, syscallnames[code], td->td_retval[0],
td->td_retval[1]);
------------------------------
Message: 4
Date: Mon, 15 Mar 2010 20:50:49 +0100 (CET)
From: Juergen Lock <n...@jelal.kn-bremen.de>
Subject: Re: How to slow down SATA to 1.5 GBit/s ?
To: scdb...@gmx.net
Cc: freebsd...@freebsd.org, m...@freebsd.org
Message-ID: <201003151950....@triton8.kn-bremen.de>
In article <1060857...@192.168.2.69> you write:
>Hi,
Hi!
>
>the switch to ahci was successful and it looks
>quite good, overall.
>
>But probably i found a bug. I could need advise
>where and how to submit it.
>
>A particular sequence of SCSI commands leads to
>an elsewise harmless stall of the dialog between
>libburn and drive.
>To close and re-open the libcam connection before
>this sequence is enough to circumvent the
>problem. But this remedy is not desirable.
>
>Long story:
>------------------------------------------------
>
>I did the switch to ahci. Now my disk is
>ada and my eSATA attached burner is not acd1|cd1
>but only cd0.
>
>The IDE ROM works fine with the vanilla
>configuration. It obviously staid under ata
>control as acd0|cd1.
>
>With the poor eSATA connection at 3000 GBit/s
>i still get the stalls. But after killing the
>writing process and about 4 minutes of waiting
>i get my drive back in most cases.
>Sometimes i have to do a power cycle on the drive
>to get it back as /dev/cd0.
>Still no reboot or panic. I begin to like ahci.
>(I find no trace of power cycle or re-plugging
> in dmesg.)
>
Ah thats good! :) You could try booting with verbose logging (I think
thats option 5. in the beastie menu that comes up at boot), maybe then
you will see something.
>
>The speed setter in camcontrol seems not to work.
>Writing still gets stuck after a few MB.
>
Is this on 8.0 release or on stable/8 or head? As I said maybe that
part of the code wasn't in 8.0 yet...
>So i used the boot time option.
>dmesg tells:
> cd0 at ahcich4 bus 0 target 0 lun 0
> cd0: <TSSTcorp CDDVDW SH-S223B SB02> Removable CD-ROM SCSI-0 device
> cd0: 300.000MB/s transfers
>
>I added to /boot/device.hints :
> hint.ahcich.4.sata_rev="1"
>
>After reboot, i see in dmesg:
> cd0 at ahcich4 bus 0 target 0 lun 0
> cd0: <TSSTcorp CDDVDW SH-S223B SB02> Removable CD-ROM SCSI-0 device
> cd0: 150.000MB/s transfers
>
>Now everything seems to work - except libburn.
>Grrr.
>
>
>Writing looks good. But it does not end.
>It is stuck in
> READ DISC INFORMATION
> 51 00 00 00 00 00 00 00 22 00
>and waits for the reply of the drive.
>This happens when the new media state shall be
>inquired after burning was completed.
>
>If i do
> cam_close_device()
>and re-open the drive, then the same command
>sequence succeeds.
>(But this is a very undesirable gesture at that
> point of processing.)
>
>The problem does not appear with USB (and did
>not while the drive was built-in at SATA).
>The drive is surely not to blame.
>
>So now i could need advise about filing a bug
>report.
>
I have Cc'd mav@ who afaik did most of the ahci(4) work, let's see what
he has to say and if he wants you to file a PR...
>------------------------------------------------
>
>Have a nice day :)
>
>Thomas
Ditto! :)
Juergen
------------------------------
Message: 5
Date: Mon, 15 Mar 2010 20:40:22 +0100 (CET)
From: Juergen Lock <n...@jelal.kn-bremen.de>
Subject: Re: How to slow down SATA to 1.5 GBit/s ?
To: scdb...@gmx.net
Cc: freebsd...@freebsd.org
Message-ID: <201003151940....@triton8.kn-bremen.de>
In article <1060635...@192.168.2.69> you write:
>Hi,
Hi!
>
>> > A leadout track. Sounds very CD-ish.
>> > With DVD and BD one should rather go for READ
>> > DISC INFORMATION and READ TRACK INFORMATION.
>
>Juergen Lock wrote:
>> Hmm you might want to followup on the PR with that hint...
>
>First i should become a less clueless newbie
>and get all my own stuff sorted out. Then
>i will probably take over the plight of ports
>maintainership from J.R. Oldroyd.
>Then i might study the sources of FreeBSD to
>find out what can be improved about DVD or BD.
>Only then i plan to become perky and tell
>other people what they should do. :))
>
Heh ok. :)
>
>> > (Switching off-and-on a stuck USB drive is
>> > obviously not a healthy thing to do.)
>> Hehe.
>
>It would be quite annoying if the machine had any
>other job than serving as OS example.
>
Well I guess we can be lucky that we do have the new usb stack now,
of course there always is room for improvement...
>
>> > First drives got stuck when disturbed while
>> > burning CD. Now the offender gets blocked until
>> > the vulnerable drive state ends.
>> [...]
>> Oh I do remember one issue: Burning usually doesn't work when hald
>> is running,
>
>I am not aware to have noticed it on FreeBSD.
> # ps -ax | fgrep hald
> 974 1 R+ 0:00.00 fgrep hald
>
>The machine runs headless resp. in console mode.
>No X, no desktop. So probably no hald.
>
Yeah hald comes with things like gnome, kde and so on, and xorg itself
now also needs it although that at least can also be configured to run
without it.
>The current behavior is quite like Alexander
>predicted it for FreeBSD back in 2006. It
>resembles the one of older SuSE Linuxes.
>
>The initial behavior, before i installed ports,
>was rather frightening. The drives got stuck
>when i accessed them while a CD was burned.
Well I guess drives simply don't like `random other' commands being
sent to them while a burn is in progress... Of course the a?cd(4)
drivers _could_ try to catch that situation and return an error or
something like that - is that what Linux does? (Actually I don't know
if hald also sends direct scsi commands via pass(4) devices, so that
may even need to be blocked too...)
>I had to shutdown -p and re-power in order to
>revive the SATA burner. USB power cycling did
>not cause a panic but the drive did not show up
>as /dev/cd* any more. A warm reboot helped.
>
>So this is on my long todo list for inspection.
>
>
>> Actually I do have siis(4) here too, will have to test that someday...
>
>With xorriso you would get a nice backup
>program. :))
>The port is a bit outdated. GNU xorriso-0.5.0
>should compile on FreeBSD out of the box.
>It is a standalone package with minimal external
>dependencies. Well suited for a test.
>
>With a SATA drive at ata i need rw-permissions
>for these device files: acd, pass, cd, xpt.
>The port of xfburn generously (or daringly)
>writes into /etc/devfs.rules :
> # rules for grip and xfburn support
> add path 'acd*' mode 0666
> add path 'cd*' mode 0666
> add path 'pass*' mode 0666
> add path 'xpt*' mode 0666
>
Ouch! :) Anyway I might give that a try once ahci(4) is working...
>
>Have a nice day :)
>
>Thomas
Ditto!
Juergen
------------------------------
Message: 6
Date: Mon, 15 Mar 2010 21:11:19 +0100
From: Juergen Lock <n...@jelal.kn-bremen.de>
Subject: Re: How to slow down SATA to 1.5 GBit/s ?
To: Juergen Lock <n...@jelal.kn-bremen.de>
Cc: freebsd...@freebsd.org, m...@freebsd.org, scdb...@gmx.net
Message-ID: <2010031520...@triton8.kn-bremen.de>
Content-Type: text/plain; charset=us-ascii
On Mon, Mar 15, 2010 at 08:50:49PM +0100, Juergen Lock wrote:
> In article <1060857...@192.168.2.69> you write:
> >Hi,
> Hi!
> >
>[ahci(4)/pass(4) optical discs burning bug...]
> >So now i could need advise about filing a bug
> >report.
> >
> I have Cc'd mav@ who afaik did most of the ahci(4) work, let's see what
> he has to say and if he wants you to file a PR...
I forgot to say if that was on 8.0 release you should try again
with stable/8 first, maybe the bug is already fixed there.
Cheers,
Juergen
------------------------------
Message: 7
Date: Mon, 15 Mar 2010 21:57:34 +0100
From: "Thomas Schmitt" <scdb...@gmx.net>
Subject: Re: How to slow down SATA to 1.5 GBit/s ?
To: freebsd...@freebsd.org
Message-ID: <1060877...@192.168.2.69>
Hi,
> I have Cc'd mav@ who afaik did most of the ahci(4) work,
I found a similar PR
http://www.mail-archive.com/freebsd...@freebsd.org/msg70510.html
and bothered mav for instructions how to upgrade
to a system that would suffice for diagnosing.
Meanwhile i suspect that there is a general
problem with SCSI commands which report error
codes. I even found a little bug in cdrskin
by watching when it gets stuck.
(SCSI error or "sense" replies are not
necessarily a sign of a program error. They
are often just part of the dialog.)
> Well I guess drives simply don't like `random other' commands being
> sent to them while a burn is in progress...
It depends on the media type.
CD and DVD-R[W] are vulnerable. It's a classic
side effect of hald.
On Linux, the burn just ends with some more or
less plausible SCSI error.
FreeBSD 8.0 freshly from DVD was less graceful.
Now it seems to know when not to let me touch
the drive. ("Now" is already before ahci.)
> I don't know if hald also sends direct scsi
> commands via pass(4) devices, so that
> may even need to be blocked too
Making drive access exclusive is quite a tragic
drama on Linux. Most burn programs rely on an
undocumented meaning of open(O_EXCL). That would
work well ... if there wasn't an older slightly
incompatible undocumented meaning.
(Cough.)
O_EXCL works on inode level, whereas we actually
would need locking on SCSI generic level, where
all possible users of a drive come together.
FreeBSD offers at least as many bypasses to the
drive as Linux does. I imagine that it is not
easy to lock them all.
I'm not done with exploring yet.
> > The port of xfburn generously (or daringly)
> > writes into /etc/devfs.rules :
> Ouch! :)
Yeah. What happened to good old group "floppy" ?
camcontrol devlist tells the particular device
files. (I learned today on my way to ahci.)
Have a nice day :)
Thomas
------------------------------
Message: 8
Date: Mon, 15 Mar 2010 22:57:24 +0100 (CET)
From: Alexander Best <alexb...@wwu.de>
Subject: Re: [patch] small fix to stop gcc warning for
lib/libstand/assert.c
To: John Baldwin <j...@freebsd.org>, Bruce Evans <br...@optusnet.com.au>
Cc: freebsd...@freebsd.org
Message-ID:
<permail-201003152157248...@message-id.uni-muenster.de>
Content-Type: text/plain; charset=us-ascii
John Baldwin schrieb am 2010-03-15:
> On Saturday 13 March 2010 08:52:19 am Alexander Best wrote:
> > hello,
> > this patch fixes the following gcc warning:
> > /usr/src/lib/libstand/assert.c:43: warning: implicit declaration of
> > function 'exit'
> > by using abort() instead of exit() (which is illegal anyway).
> > looking at
> > lib/libc/gen/assert.c abort() seems save to use instead of exit().
> There is no abort() in libstand or any of the boot code. If you
> built a full
> world with this change you should have gotten a link error for
> /boot/loader.
> exit() is required by the boot code however (see
> sys/boot/common/panic.c).
> The use of exit() instead of abort() here is on purpose. This is the
> fix I
> would use.
indeed your patch seems a lot more reasonable than the one i proposed. i think
this could go directly into head. i'll run buildworld overnight to see if all
goes well.
btw: i've checked and exit() is used in assert.c on all major *bsd version
(netbsd, openbsd, dragonfly).
cheers.
alex
ps: i've opened a pr under misc/144749. you might want to submit your patch as
followup.
> I would not add 'exit()' to <stand.h> as it is not an
> interface
> that libstand provides, but one that it requires from the environment
> it is
> linked with.
> Index: assert.c
> ===================================================================
> --- assert.c (revision 204953)
> +++ assert.c (working copy)
> @@ -31,6 +31,8 @@
> #include "stand.h"
> +void exit(int);
> +
> void
> __assert(const char *func, const char *file, int line, const char
> *expression)
> {
> @@ -40,5 +42,5 @@
> else
> printf("Assertion failed: (%s), function %s, file %s,
> line "
> "%d.\n", expression, func, file, line);
> - exit();
> + exit(1);
> }
------------------------------
Message: 9
Date: Tue, 16 Mar 2010 00:30:37 +0200
From: Alexander Motin <m...@FreeBSD.org>
Subject: Re: How to slow down SATA to 1.5 GBit/s ?
To: Juergen Lock <n...@jelal.kn-bremen.de>
Cc: freebsd...@freebsd.org, scdb...@gmx.net
Message-ID: <4B9EB50D...@FreeBSD.org>
Content-Type: text/plain; charset=KOI8-R
Juergen Lock wrote:
>> The speed setter in camcontrol seems not to work.
>> Writing still gets stuck after a few MB.
>>
> Is this on 8.0 release or on stable/8 or head? As I said maybe that
> part of the code wasn't in 8.0 yet...
AFAIR it was implemented later then 8.0-RELEASE, and it works via:
camcontrol negotiate cd0 -U -R 1500000
camcontrol reset 4
>> So i used the boot time option.
>> dmesg tells:
>> cd0 at ahcich4 bus 0 target 0 lun 0
>> cd0: <TSSTcorp CDDVDW SH-S223B SB02> Removable CD-ROM SCSI-0 device
>> cd0: 300.000MB/s transfers
>>
>> I added to /boot/device.hints :
>> hint.ahcich.4.sata_rev="1"
>>
>> After reboot, i see in dmesg:
>> cd0 at ahcich4 bus 0 target 0 lun 0
>> cd0: <TSSTcorp CDDVDW SH-S223B SB02> Removable CD-ROM SCSI-0 device
>> cd0: 150.000MB/s transfers
That way is also working.
--
Alexander Motin
------------------------------
Message: 10
Date: Tue, 16 Mar 2010 00:31:26 +0200
From: Alexander Motin <m...@FreeBSD.org>
Subject: Re: How to slow down SATA to 1.5 GBit/s ?
To: Juergen Lock <n...@jelal.kn-bremen.de>
Cc: freebsd...@freebsd.org, scdb...@gmx.net
Message-ID: <4B9EB53E...@FreeBSD.org>
Content-Type: text/plain; charset=ISO-8859-1
Juergen Lock wrote:
> On Mon, Mar 15, 2010 at 08:50:49PM +0100, Juergen Lock wrote:
>> In article <1060857...@192.168.2.69> you write:
>>> Hi,
>> Hi!
>> [ahci(4)/pass(4) optical discs burning bug...]
>
>>> So now i could need advise about filing a bug
>>> report.
>>>
>> I have Cc'd mav@ who afaik did most of the ahci(4) work, let's see what
>> he has to say and if he wants you to file a PR...
>
> I forgot to say if that was on 8.0 release you should try again
> with stable/8 first, maybe the bug is already fixed there.
Definitely. Many things were changed/fixed there.
--
Alexander Motin
------------------------------
Message: 11
Date: Mon, 15 Mar 2010 23:34:53 +0100
From: Ivan Radovanovic <riv...@gmail.com>
Subject: Problem with Realtek NIC
To: freebsd...@FreeBSD.org
Message-ID: <4B9EB60D...@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hello,
I am experiencing weird problem with Realtek network card under FreeBSD.
Recently (10 days ago) I cvsup-ed to RELENG_7, so that may be the cause
of problem too (although I noticed this only last 2-3 days).
Network card looses connectivity in some way after around 1 hour of
being connected - "in some way" because I am able to ping gateway for
example but large number of packets is dropped (like first 15 going
through, then 40 without reply and so on). If I do
ifconfig re0 down and after that ifconfig re0 up everything is restored
to working state for another hour. I tested the same machine under
windows and everything seems to work normaly. I tried ifconfig re0
-txcsum -rxcsum but that didn't have any effect.
Data from dmesg
re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet>
port 0xc400-0xc4ff mem 0xfeaff800-0xfeaff8ff irq 20 at device 4.0 on pci2
re0: Chip rev. 0x10000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
Any help would be greatly appreciated
Regards,
Ivan
------------------------------
Message: 12
Date: Mon, 15 Mar 2010 21:09:09 -0400 (EDT)
From: george+...@m5p.com
Subject: flash drive crashes hald on amd64
To: freebsd...@freebsd.org
Message-ID: <201003160109....@m5p.com>
HP Compaq Presario CQ61-420US (dual core amd64)
With an Iomega USB flash drive inserted into a USB slot at the time
hald starts, it crashes:
pid 903 (hald), uid 560: exited on signal 11
pid 943 (hald-probe-volume), uid 0: exited on signal 6 (core dumped)
It's okay if I insert the flash drive after hald has started, but
the flash drive is normally left in the slot all the time, leading
to unhappiness every time the computer is started. There's no sign
of the alleged core file, so I don't know how to debug this problem
-- George Mitchell
------------------------------
Message: 13
Date: Mon, 15 Mar 2010 21:24:06 -0400 (EDT)
From: george+...@m5p.com
Subject: Re: flash drive crashes hald on amd64
To: freebsd...@freebsd.org
Message-ID: <201003160124....@m5p.com>
> HP Compaq Presario CQ61-420US (dual core amd64)
I forgot to mention: FreeBSD 8.0-RELEASE
> With an Iomega USB flash drive inserted into a USB slot at the time
> hald starts, it crashes:
>
> pid 903 (hald), uid 560: exited on signal 11
> pid 943 (hald-probe-volume), uid 0: exited on signal 6 (core dumped)
>
> It's okay if I insert the flash drive after hald has started, but
> the flash drive is normally left in the slot all the time, leading
> to unhappiness every time the computer is started. There's no sign
> of the alleged core file, so I don't know how to debug this problem
> -- George Mitchell
------------------------------
End of freebsd-hackers Digest, Vol 364, Issue 2
***********************************************