Re: How to report bugs (Re: 6.2-STABLE deadlock?)
On Saturday 28 April 2007 04:33, Marc G. Fournier wrote: > A thought: how hard would it be to add some method of forcing a > system crash, that would dump core, from the command line? Something > that, by default, would be disabled, but for remote debugging > purposes, one could enable in the kernel and do a 'sysctl > kernel.force_core_crash=1' to have it do it? I imagine that having a > core to analyze would allow providing more information then nothing > at all, no? I think you can do this.. sysctl debug.kdb.panic=1 Alas that appears to be a -current thing. 6.x has debug.kdb.enter though. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp1RMXdUwoh1.pgp Description: PGP signature
Re: kern/112119: system hangs when starts k3b on RELENG_6
On Fri, 27 Apr 2007 14:28:14 -0600
Scott Long <[EMAIL PROTECTED]> wrote:
> Thomas Quinot wrote:
> > * Scott Long, 2007-04-27 :
> >
> >> Oh hell, I know exactly what the problem is! The opcode for a
> >> TEST_UNIT_READY is 0x00. This is probably the command that is
> >> generating the CHECK_CONDITION. The test for saved_cmd is entirely
> >> bogus.
> >
> > H. Looks like a very plausible culprit. Good catch Scott!
> > (I felt there had to be something wrong when I wrote that test,
> > incidentally, precisely because of TEST_UNIT_READY).
> >
> > Nikolay, Ganbold, (and others), here's another patch against
> > 1.42.2.3, please let me know if it works for you.
> >
> > Thomas.
> >
> > Index: atapi-cam.c
> > ===
> > RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v
> > retrieving revision 1.50
> > diff -u -r1.50 atapi-cam.c
> > --- atapi-cam.c 14 Mar 2007 01:59:00 - 1.50
> > +++ atapi-cam.c 27 Apr 2007 19:26:09 -
> > @@ -729,7 +743,7 @@
> > * issued a REQUEST SENSE automatically and that
> > operation
> > * returned without error.
> > */
> > - if (request->u.atapi.saved_cmd != 0 &&
> > request->error == 0) {
> > + if (request->u.atapi.sense.key != 0 &&
> > request->error == 0) { bcopy (&request->u.atapi.sense,
> > &csio->sense_data, sizeof(struct atapi_sense)); csio->ccb_h.status
> > |= CAM_AUTOSNS_VALID; }
>
> Right, just make sure that this isn't filled with garbage before you
> send the command. If you're using ata_alloc_request(), and you're not
> recycling requests internally, then you should be fine.
>
> Scott
>
I just installed this patch on my i386 system and I can now start K3B
without the system crashing.
I still have this in dmesg when starting the system:
acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
And this in /var/log/messages each time I start K3B
Apr 27 10:47:39 p4 kernel: acd1: FAILURE - MODE_SENSE_BIG ILLEGAL
REQUEST asc=0x24 ascq=0x00 Apr 27 10:47:39 p4 last message repeated 3
times Apr 27 10:52:07 p4 kernel: acd1: FAILURE - MODE_SENSE_BIG ILLEGAL
REQUEST asc=0x24 ascq=0x00
I successfully burned an audio CD even with the above errors. The patch
seems to work. I will try it on my amd64 machine and report if it does
not work there.
Thank you
Robert
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 induced panic additional info
On Fri, Apr 27, 2007 at 02:26:15PM -0700, Sam Leffler wrote: > Steve Kargl wrote: > > By increasing the kernel message buffer, I was able to > > get the previous "Unread portion" im my last email. > > > > Unread portion of the kernel message buffer: > > lock order reversal: (sleepable after non-sleepable) > > 1st 0xc34caec0 ath0 (ath0) @ /usr/src/sys/dev/ath/if_ath.c:5210 > > 2nd 0xc32cbe24 user map (user map) @ /usr/src/sys/vm/vm_map.c:3074 > > --- trap 0xc, eip = 0xc06e8056, esp = 0xd9753b74, ebp = 0xd9753bac --- > > generic_copyout(c34c8c00,c3726400,c34cab30,,...) at generic_copyout+0x36 > > ieee80211_ioctl(c34ca230,c0286938,c3726400) at ieee80211_ioctl+0xc1 > > ath_ioctl(c34c8c00,c0286938,c3726400) at ath_ioctl+0x190 > > Age old issue: the driver calls into the net80211 layer holding it's > softc lock but net80211 calls copyout and if that faults copying data to > user mode then you'll blow up. I've proposed a solution but noone's > responded so it remains. > That's unfortunate. :( OTOH, I've since updated the laptop to -current and ath0 is working great. Thanks for your effort on this driver and other parts of FreeBSD. -- Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to report bugs (Re: 6.2-STABLE deadlock?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, April 27, 2007 22:57:29 +0200 Nicolas Rachinsky <[EMAIL PROTECTED]> wrote: > * "Marc G. Fournier" <[EMAIL PROTECTED]> [2007-04-27 16:03 -0300]: >> A thought: how hard would it be to add some method of forcing a system >> crash, that would dump core, from the command line? Something that, by >> default, would > > Doesn't 'kill -6 1' work anymore? I'd never heard of that one ... will it dump core if I do that? Please note, in my case, with the Buffer Space issue ... I can login and cleanly reboot the server, so doing something like the above to get a core dump is definitely doable, I'd just never seen a reference to a 'kill -6 1' before for doing that ... Side question to this though ... I remember awhile back using a 'client-server' mechanism that allowed me to dump core to a seperate server ... it was so long ago that my memory is faint, but there was a reason why I couldn't dump to the local server ... not sure whatever happened to that code, but, if one can do that for dumping core, shouldn't there be some method possible to connect to DDB over the Ethernet without having to have a serial console in place? For the core dump case, the ethernet obviously stayed up while it dump'd, couldn't some sort of 'ddb.conf' file be setup that would allow it to ifconfig an IP within that shell so that you could connect to it remotely? say with an 'from-ip' directive? Just a thought ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGMmx04QvfyHIvDvMRAlNcAJ0QcIMoRnq+0T9yJVuMwZvTNQnNXwCfaEKK JB4cHzSbiklD/sodWvNSSzE= =BwuL -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: ath0 induced panic additional info
Steve Kargl wrote: > By increasing the kernel message buffer, I was able to > get the previous "Unread portion" im my last email. > > Unread portion of the kernel message buffer: > lock order reversal: (sleepable after non-sleepable) > 1st 0xc34caec0 ath0 (ath0) @ /usr/src/sys/dev/ath/if_ath.c:5210 > 2nd 0xc32cbe24 user map (user map) @ /usr/src/sys/vm/vm_map.c:3074 > KDB: stack backtrace: > kdb_backtrace(0,,c07c3e08,c07c5500,c078596c,...) at kdb_backtrace+0x29 > witness_checkorder(c32cbe24,9,c075587c,c02) at witness_checkorder+0x578 > _sx_xlock(c32cbe24,c075587c,c02) at _sx_xlock+0x50 > _vm_map_lock_read(c32cbde0,c075587c,c02,2000246,c3722068,...) at > _vm_map_lock_read+0x37 > vm_map_lookup(d9753a6c,805e000,2,d9753a70,d9753a60,d9753a64,d9753a47,d9753a48) > at vm_map_lookup+0x28 > vm_fault(c32cbde0,805e000,2,8,c34ee180,...) at vm_fault+0x65 > trap_pfault(d9753b34,0,805e000) at trap_pfault+0xce > trap(c07b0008,28,c0730028,805e000,c334f400,...) at trap+0x319 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc06e8056, esp = 0xd9753b74, ebp = 0xd9753bac --- > generic_copyout(c34c8c00,c3726400,c34cab30,c0286938,0,...) at > generic_copyout+0x36 > ieee80211_ioctl(c34ca230,c0286938,c3726400) at ieee80211_ioctl+0xc1 > ath_ioctl(c34c8c00,c0286938,c3726400) at ath_ioctl+0x190 > ifhwioctl(c0286938,c34c8c00,c3726400,c34ee180) at ifhwioctl+0xa40 > ifioctl(c355e000,c0286938,c3726400,c34ee180,0,...) at ifioctl+0xc3 > soo_ioctl(c3516ab0,c0286938,c3726400,c3748480,c34ee180) at soo_ioctl+0x2db > ioctl(c34ee180,d9753d04) at ioctl+0x396 > syscall(3b,3b,3b,805d028,0,...) at syscall+0x22f > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28149787, esp = 0xbfbfe2fc, > ebp = 0xbfbfe328 --- > KDB: enter: witness_checkorder > panic: from debugger > KDB: stack backtrace: > Uptime: 1m1s > Dumping 511 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 511MB (130786 pages) 495 479 463 447 431 415 399 383 367 351 335 > 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 > > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) quit > mobile:root[157] exit > exit > > Script done on Thu Apr 26 16:38:51 2007 Age old issue: the driver calls into the net80211 layer holding it's softc lock but net80211 calls copyout and if that faults copying data to user mode then you'll blow up. I've proposed a solution but noone's responded so it remains. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to report bugs (Re: 6.2-STABLE deadlock?)
* "Marc G. Fournier" <[EMAIL PROTECTED]> [2007-04-27 16:03 -0300]: > A thought: how hard would it be to add some method of forcing a system crash, > that would dump core, from the command line? Something that, by default, > would Doesn't 'kill -6 1' work anymore? Nicolas -- http://www.rachinsky.de/nicolas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
Thomas Quinot wrote:
* Scott Long, 2007-04-27 :
Oh hell, I know exactly what the problem is! The opcode for a
TEST_UNIT_READY is 0x00. This is probably the command that is
generating the CHECK_CONDITION. The test for saved_cmd is entirely
bogus.
H. Looks like a very plausible culprit. Good catch Scott!
(I felt there had to be something wrong when I wrote that test,
incidentally, precisely because of TEST_UNIT_READY).
Nikolay, Ganbold, (and others), here's another patch against 1.42.2.3,
please let me know if it works for you.
Thomas.
Index: atapi-cam.c
===
RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v
retrieving revision 1.50
diff -u -r1.50 atapi-cam.c
--- atapi-cam.c 14 Mar 2007 01:59:00 - 1.50
+++ atapi-cam.c 27 Apr 2007 19:26:09 -
@@ -729,7 +743,7 @@
* issued a REQUEST SENSE automatically and that operation
* returned without error.
*/
- if (request->u.atapi.saved_cmd != 0 && request->error == 0) {
+ if (request->u.atapi.sense.key != 0 && request->error == 0) {
bcopy (&request->u.atapi.sense, &csio->sense_data,
sizeof(struct atapi_sense));
csio->ccb_h.status |= CAM_AUTOSNS_VALID;
}
Right, just make sure that this isn't filled with garbage before you
send the command. If you're using ata_alloc_request(), and you're not
recycling requests internally, then you should be fine.
Scott
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
* Scott Long, 2007-04-27 :
> Oh hell, I know exactly what the problem is! The opcode for a
> TEST_UNIT_READY is 0x00. This is probably the command that is
> generating the CHECK_CONDITION. The test for saved_cmd is entirely
> bogus.
H. Looks like a very plausible culprit. Good catch Scott!
(I felt there had to be something wrong when I wrote that test,
incidentally, precisely because of TEST_UNIT_READY).
Nikolay, Ganbold, (and others), here's another patch against 1.42.2.3,
please let me know if it works for you.
Thomas.
Index: atapi-cam.c
===
RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v
retrieving revision 1.50
diff -u -r1.50 atapi-cam.c
--- atapi-cam.c 14 Mar 2007 01:59:00 - 1.50
+++ atapi-cam.c 27 Apr 2007 19:26:09 -
@@ -729,7 +743,7 @@
* issued a REQUEST SENSE automatically and that operation
* returned without error.
*/
- if (request->u.atapi.saved_cmd != 0 && request->error == 0) {
+ if (request->u.atapi.sense.key != 0 && request->error == 0) {
bcopy (&request->u.atapi.sense, &csio->sense_data,
sizeof(struct atapi_sense));
csio->ccb_h.status |= CAM_AUTOSNS_VALID;
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
Nikolay Pavlov wrote:
On Friday, 27 April 2007 at 17:32:18 +0200, Thomas Quinot wrote:
* Ganbold.TS, 2007-04-27 :
I tried your patch at
http://www.freebsd.org/cgi/query-pr.cgi?pr=103602&getpatch=12 and the
problem is still the same. Ssytem freezes upon start of k3b.
I also tried your attached patch, which reverts part of rev. 1.42.2.3
and the problem is still the same, system hangs when starts k3b.
Thanks, that's useful info. Please try the attached patch instead, which
reverts another part of 1.42.2.3 (I'm trying to figure out exactly
*which* part of this change is causing the problem).
Also, were you able to capture system console output at the point where
the crash occurs? We might have some indications there.
This patch works for me. I do not have a reboot and i am able to
succesfully burn a cd.
Thomas.
Index: atapi-cam.c
===
RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v
retrieving revision 1.42.2.3
retrieving revision 1.42.2.2
diff -u -r1.42.2.3 -r1.42.2.2
--- atapi-cam.c 29 Mar 2007 20:08:32 - 1.42.2.3
+++ atapi-cam.c 6 Mar 2007 16:56:50 - 1.42.2.2
@@ -697,39 +680,32 @@
csio->ccb_h.status |= CAM_AUTOSNS_VALID;
}
} else if (request->result != 0) {
- if ((request->flags & ATA_R_TIMEOUT) != 0) {
- rc = CAM_CMD_TIMEOUT;
- } else {
- rc = CAM_SCSI_STATUS_ERROR;
- csio->scsi_status = SCSI_STATUS_CHECK_COND;
+ rc = CAM_SCSI_STATUS_ERROR;
+ csio->scsi_status = SCSI_STATUS_CHECK_COND;
- if ((csio->ccb_h.flags & CAM_DIS_AUTOSENSE) == 0) {
+ if ((csio->ccb_h.flags & CAM_DIS_AUTOSENSE) == 0) {
#if 0
- static const int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0,
- sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0 };
-
- bcopy (ccb, request->u.atapi.ccb, sizeof ccb);
- request->data = (caddr_t)&csio->sense_data;
- request->bytecount = sizeof(struct atapi_sense);
- request->transfersize = min(request->bytecount, 65534);
- request->timeout = csio->ccb_h.timeout / 1000;
- request->retries = 2;
- request->flags = ATA_R_QUIET|ATA_R_ATAPI|ATA_R_IMMEDIATE;
- hcb->flags |= AUTOSENSE;
+ static const int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0,
+ sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0 };
+
+ bcopy (ccb, request->u.atapi.ccb, sizeof ccb);
+ request->data = (caddr_t)&csio->sense_data;
+ request->bytecount = sizeof(struct atapi_sense);
+ request->transfersize = min(request->bytecount, 65534);
+ request->timeout = csio->ccb_h.timeout / 1000;
+ request->retries = 2;
+ request->flags = ATA_R_QUIET|ATA_R_ATAPI|ATA_R_IMMEDIATE;
+ hcb->flags |= AUTOSENSE;
- ata_queue_request(request);
- return;
+ ata_queue_request(request);
+ return;
#else
- /*
-* Use auto-sense data from the ATA layer, if it has
-* issued a REQUEST SENSE automatically and that operation
-* returned without error.
-*/
- if (request->u.atapi.saved_cmd != 0 && request->error == 0) {
- bcopy (&request->u.atapi.sense, &csio->sense_data,
sizeof(struct atapi_sense));
- csio->ccb_h.status |= CAM_AUTOSNS_VALID;
- }
+ /* The ATA driver has already requested sense for us. */
+ if (request->error == 0) {
+ /* The ATA autosense suceeded. */
+ bcopy (&request->u.atapi.sense, &csio->sense_data,
sizeof(struct atapi_sense));
+ csio->ccb_h.status |= CAM_AUTOSNS_VALID;
}
#endif
}
My best guess is that request->u.atapi.saved_cmd isn't getting preserved
when ata_completed() does an automatic REQUEST_SENSE. Not sure if this
is true or why it would happen. But if that's the case, then CAM is
going to manually request sense, which atapi-cam and ata will likely
treat as a normal DMA capable command. Note that the autosense code in
the ATA driver disables DMA for the REQUEST_SENSE command. This might
be a key issue; the drive might be getting very unhappy with a DMA
flagged REQUEST_SENSE command, especially if it's already in a
CHECK_CONDITION state. This unhappiness might be leading to the
interrupt storm and observed deadlock on UP system.
With the patch above, sense info is reported to CAM regardless of the
contents of saved_cmd, preventing CAM from generating the troublesome
REQUEST_SENSE on its own.
Oh hell, I know exactly what the problem is! The opcode for a
TEST_UNIT_READY is 0x00. This is probably the command that is
generating the CHECK_CONDITION. The test for saved_cmd is entirely
bogus. W
Re: How to report bugs (Re: 6.2-STABLE deadlock?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Tuesday, April 24, 2007 23:53:16 -0400 Kris Kennaway <[EMAIL PROTECTED]> wrote: > On Wed, Apr 25, 2007 at 10:53:08AM +0800, LI Xin wrote: >> Hi, Oleg, >> >> Oleg Derevenetz wrote: >> > ??? LI Xin <[EMAIL PROTECTED]>: >> [...] >> >> I'm not very sure if this is specific to one disk controller. Actually >> >> I got some occasional reports about similar hangs on amd64 6.2-RELEASE >> >> (slightly patched version) that most of processes stuck in the 'ufs' >> >> state, under very light load, the box was equipped with amr(4) RAID. >> >> >> >> I was not able to reproduce the problem at my lab, though, it's still >> >> unknown that how to trigger the livelock :-( Still need some >> >> investigate on their production system. >> > >> > I reported simular issue for FreeBSD 6.2 in audit-trail for kern/104406: >> > >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=104406&cat= >> > >> > and there should be a thread related to this. Briefly, I suspects that >> > this is related to nullfs filesystems on my server and when I cvsuped to >> > FreeBSD 6.2- STABLE with Daichi's unionfs-related patches and replaced >> > nullfs-mounted fs with unionfs-mounted (that was done 10.03.07) problem >> > is gone (seems to be so, at least). >> >> Hmm... Seems to be different issues. The problem I have received was a >> pgsql server (no nullfs/unionfs involved), and the hang always happen >> when it is not being heavily loaded (usually in the morning, for >> instance, and there is no special configuration, like scheduled tasks >> which can generate disk load, etc., only the entropy harvesting), so >> this is quite confusing. > > Yes, a large part of the confusion is the unfortunate tendency of > people to do the following: > > my system hangs/panics/etc > my system hangs/panics/etc too; it must be the same problem! > > What we really need is for every FreeBSD user who encounters a > hang/panic/etc to avoid jumping to conclusions -- no matter how many > superficial similarities there may seem to you -- and instead go > through the relevant steps described here: > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernelde > bug.html > > Until you (or a developer) have analyzed the resulting information, > you cannot definitively determine whether or not your problem is the > same as a given random other problem, and you may just confuse the > issue by making claims of similarity when you are really reporting a > completely separate problem. What about those that don't have the benefit of being able to access the console? :( I've recently started buying servers that have builtin, full remote console (ie. the HP servers), but, for instance, I have one box that I have to consistently reboot ever 3 days due to a 'No Buffer Space Available' ... A thought: how hard would it be to add some method of forcing a system crash, that would dump core, from the command line? Something that, by default, would be disabled, but for remote debugging purposes, one could enable in the kernel and do a 'sysctl kernel.force_core_crash=1' to have it do it? I imagine that having a core to analyze would allow providing more information then nothing at all, no? - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGMkj34QvfyHIvDvMRAnIsAJ42loBGh0TkX4mfWSrZrMq2FheBuQCgiu4l B0PCLtLhd9ZiJ4oNLWZ6LT0= =KK9Y -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: kern/112119: system hangs when starts k3b on RELENG_6
On Friday, 27 April 2007 at 17:32:18 +0200, Thomas Quinot wrote:
> * Ganbold.TS, 2007-04-27 :
>
> > I tried your patch at
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=103602&getpatch=12 and the
> > problem is still the same. Ssytem freezes upon start of k3b.
> >
> > I also tried your attached patch, which reverts part of rev. 1.42.2.3
> > and the problem is still the same, system hangs when starts k3b.
>
> Thanks, that's useful info. Please try the attached patch instead, which
> reverts another part of 1.42.2.3 (I'm trying to figure out exactly
> *which* part of this change is causing the problem).
>
> Also, were you able to capture system console output at the point where
> the crash occurs? We might have some indications there.
This patch works for me. I do not have a reboot and i am able to
succesfully burn a cd.
>
> Thomas.
>
> Index: atapi-cam.c
> ===
> RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v
> retrieving revision 1.42.2.3
> retrieving revision 1.42.2.2
> diff -u -r1.42.2.3 -r1.42.2.2
> --- atapi-cam.c 29 Mar 2007 20:08:32 - 1.42.2.3
> +++ atapi-cam.c 6 Mar 2007 16:56:50 - 1.42.2.2
> @@ -697,39 +680,32 @@
> csio->ccb_h.status |= CAM_AUTOSNS_VALID;
> }
> } else if (request->result != 0) {
> - if ((request->flags & ATA_R_TIMEOUT) != 0) {
> - rc = CAM_CMD_TIMEOUT;
> - } else {
> - rc = CAM_SCSI_STATUS_ERROR;
> - csio->scsi_status = SCSI_STATUS_CHECK_COND;
> + rc = CAM_SCSI_STATUS_ERROR;
> + csio->scsi_status = SCSI_STATUS_CHECK_COND;
>
> - if ((csio->ccb_h.flags & CAM_DIS_AUTOSENSE) == 0) {
> + if ((csio->ccb_h.flags & CAM_DIS_AUTOSENSE) == 0) {
> #if 0
> - static const int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0,
> - sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0,
> - 0, 0, 0, 0, 0 };
> -
> - bcopy (ccb, request->u.atapi.ccb, sizeof ccb);
> - request->data = (caddr_t)&csio->sense_data;
> - request->bytecount = sizeof(struct atapi_sense);
> - request->transfersize = min(request->bytecount, 65534);
> - request->timeout = csio->ccb_h.timeout / 1000;
> - request->retries = 2;
> - request->flags = ATA_R_QUIET|ATA_R_ATAPI|ATA_R_IMMEDIATE;
> - hcb->flags |= AUTOSENSE;
> + static const int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0,
> + sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0,
> + 0, 0, 0, 0, 0 };
> +
> + bcopy (ccb, request->u.atapi.ccb, sizeof ccb);
> + request->data = (caddr_t)&csio->sense_data;
> + request->bytecount = sizeof(struct atapi_sense);
> + request->transfersize = min(request->bytecount, 65534);
> + request->timeout = csio->ccb_h.timeout / 1000;
> + request->retries = 2;
> + request->flags = ATA_R_QUIET|ATA_R_ATAPI|ATA_R_IMMEDIATE;
> + hcb->flags |= AUTOSENSE;
>
> - ata_queue_request(request);
> - return;
> + ata_queue_request(request);
> + return;
> #else
> - /*
> - * Use auto-sense data from the ATA layer, if it has
> - * issued a REQUEST SENSE automatically and that operation
> - * returned without error.
> - */
> - if (request->u.atapi.saved_cmd != 0 && request->error == 0) {
> - bcopy (&request->u.atapi.sense, &csio->sense_data,
> sizeof(struct atapi_sense));
> - csio->ccb_h.status |= CAM_AUTOSNS_VALID;
> - }
> + /* The ATA driver has already requested sense for us. */
> + if (request->error == 0) {
> + /* The ATA autosense suceeded. */
> + bcopy (&request->u.atapi.sense, &csio->sense_data,
> sizeof(struct atapi_sense));
> + csio->ccb_h.status |= CAM_AUTOSNS_VALID;
> }
> #endif
> }
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
==
- Best regards, Nikolay Pavlov. <<<---
==
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: xfce4 desktop broken, complaining about libmd5.so.1
Chris Rees <[EMAIL PROTECTED]> wrote: > Maybe I should suggest adding libwww as dependiencies to xfce4 You should talk to the port's maintainer about that. However, it's not always a trivial thing to get all the possible dependencies right. Sometimes the configure script of a software happens to find a library and decides to use it and to link against it, even though it is purely optional, and the port maintainer didn't think about the possibility. Such cases aren't detected by a clean build when the library in question is not installed (such as on the FreeBSD package cluster). Of course, the opposite case _is_ detected: If a software requires a library (i.e. it's non-optional), then it will break if the library is not present. So, in fact, simply re-installing libwww will make it work, but it might still cause problems in the long run (e.g. at an update in the future), because the dependencies are still incorrectly recorded. You have two options: 1. Install libwww and fix the dependencies manually: - Add a line "@pkgdep libwww-..." to the file /var/db/pkg/xfce-.../+CONTENTS - Add a line "xfce-..." to the file /var/db/pkg/libwww-.../+REQUIRED_BY. If you use portupgrade, you probably have to rebuild its database. 2. Do _not_ install libwww, and instead rebuild xfce4. Then the configure script will not find libwww and will not link against it. Well, at least that's the theory. :-) 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 C++: "an octopus made by nailing extra legs onto a dog" -- Steve Taylor, 1998 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: xfce4 desktop broken, complaining about libmd5.so.1
Ah, brilliant! Thanks, I knew there was a way like that, but six hours' googling didn't find it, though I'm sure it was just me being thick! Maybe I should suggest adding libwww as dependiencies to xfce4, or maybe I shouldn't just delete ports without making a careful list... On 27/04/07, Daniel O'Connor <[EMAIL PROTECTED]> wrote: On Friday 27 April 2007 20:48, Oliver Fromme wrote: > Oliver Fromme wrote: > > Just a small addendum _how_ to find it out: > > > > $ cd /usr/ports > > $ echo */*/pkg-plist | xargs grep libmd5.so.1 > > I'm very sorry for repeatedly replying to myself, but I > almost forgot that there's a much faster way to find the > port which has that library: > > http://www.secnetix.de/tools/porgle/ > > Enter "libmd5.so.1" into the search field, check the > "packing list" checkbox, and click the "Search" button. I suspect both of these methods wouldn't help if the plist was dynamically generated (alas) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: xfce4 desktop broken, complaining about libmd5.so.1
Daniel O'Connor wrote: > Oliver Fromme wrote: > > Oliver Fromme wrote: > > > $ cd /usr/ports > > > $ echo */*/pkg-plist | xargs grep libmd5.so.1 > > [...] > > http://www.secnetix.de/tools/porgle/ > > > > Enter "libmd5.so.1" into the search field, check the > > "packing list" checkbox, and click the "Search" button. > > I suspect both of these methods wouldn't help if the plist was > dynamically generated (alas) Yes, that's correct, at least for the first method (grep). I mentioned that in the previous mail (it was omitted from the quote): > (That approach works for most ports and files, but > not for all of them. Some ports generate their > packing list (plist) dynamically, but fortunately > those are a small minority.) However, the second method uses a few hacks so the plist files from most ports are included, even dynamically generated ones. There are still a few exceptions, in particular those linux ports that use AUTOMATIC_PLIST, but those are only 10 out of 16,925 ... so I'm not terribly worried. :-) For example, searching for "inflate.java" will correctly find the port archivers/jzlib, even though that port generates its plist dynamically. 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 "C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months." -- Cliff Sarginson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
* Ganbold.TS, 2007-04-27 :
> I tried your patch at
> http://www.freebsd.org/cgi/query-pr.cgi?pr=103602&getpatch=12 and the
> problem is still the same. Ssytem freezes upon start of k3b.
>
> I also tried your attached patch, which reverts part of rev. 1.42.2.3
> and the problem is still the same, system hangs when starts k3b.
Thanks, that's useful info. Please try the attached patch instead, which
reverts another part of 1.42.2.3 (I'm trying to figure out exactly
*which* part of this change is causing the problem).
Also, were you able to capture system console output at the point where
the crash occurs? We might have some indications there.
Thomas.
Index: atapi-cam.c
===
RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v
retrieving revision 1.42.2.3
retrieving revision 1.42.2.2
diff -u -r1.42.2.3 -r1.42.2.2
--- atapi-cam.c 29 Mar 2007 20:08:32 - 1.42.2.3
+++ atapi-cam.c 6 Mar 2007 16:56:50 - 1.42.2.2
@@ -697,39 +680,32 @@
csio->ccb_h.status |= CAM_AUTOSNS_VALID;
}
} else if (request->result != 0) {
- if ((request->flags & ATA_R_TIMEOUT) != 0) {
- rc = CAM_CMD_TIMEOUT;
- } else {
- rc = CAM_SCSI_STATUS_ERROR;
- csio->scsi_status = SCSI_STATUS_CHECK_COND;
+ rc = CAM_SCSI_STATUS_ERROR;
+ csio->scsi_status = SCSI_STATUS_CHECK_COND;
- if ((csio->ccb_h.flags & CAM_DIS_AUTOSENSE) == 0) {
+ if ((csio->ccb_h.flags & CAM_DIS_AUTOSENSE) == 0) {
#if 0
- static const int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0,
- sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0 };
-
- bcopy (ccb, request->u.atapi.ccb, sizeof ccb);
- request->data = (caddr_t)&csio->sense_data;
- request->bytecount = sizeof(struct atapi_sense);
- request->transfersize = min(request->bytecount, 65534);
- request->timeout = csio->ccb_h.timeout / 1000;
- request->retries = 2;
- request->flags = ATA_R_QUIET|ATA_R_ATAPI|ATA_R_IMMEDIATE;
- hcb->flags |= AUTOSENSE;
+ static const int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0,
+ sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0 };
+
+ bcopy (ccb, request->u.atapi.ccb, sizeof ccb);
+ request->data = (caddr_t)&csio->sense_data;
+ request->bytecount = sizeof(struct atapi_sense);
+ request->transfersize = min(request->bytecount, 65534);
+ request->timeout = csio->ccb_h.timeout / 1000;
+ request->retries = 2;
+ request->flags = ATA_R_QUIET|ATA_R_ATAPI|ATA_R_IMMEDIATE;
+ hcb->flags |= AUTOSENSE;
- ata_queue_request(request);
- return;
+ ata_queue_request(request);
+ return;
#else
- /*
-* Use auto-sense data from the ATA layer, if it has
-* issued a REQUEST SENSE automatically and that operation
-* returned without error.
-*/
- if (request->u.atapi.saved_cmd != 0 && request->error == 0) {
- bcopy (&request->u.atapi.sense, &csio->sense_data,
sizeof(struct atapi_sense));
- csio->ccb_h.status |= CAM_AUTOSNS_VALID;
- }
+ /* The ATA driver has already requested sense for us. */
+ if (request->error == 0) {
+ /* The ATA autosense suceeded. */
+ bcopy (&request->u.atapi.sense, &csio->sense_data,
sizeof(struct atapi_sense));
+ csio->ccb_h.status |= CAM_AUTOSNS_VALID;
}
#endif
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
On Friday, 27 April 2007 at 9:40:19 +0800, Ganbold wrote: > Thomas Quinot wrote: > >* Ganbold, 2007-04-25 : > > > > > >>>Description: > >>> > >>With atapi-cam.c (rev 1.42.2.3) when running k3b application, system > >>completely hangs on k3b splash screen and I had to use power button only > >>to restart the machine. > >> > > > >Extremely strange. I can't offer any definite solution at this point, > >since I have no idea how this change could cause a system to hang. Here > >are a few possible investigation ideas: > > > >* AFAIK k3b is just a front-end for command-line tools. You should > > determine what exact commands are spawned by k3b to identify which of > > these is causing the apparent hang; > > > >* it would also be useful to enable CAM debugging options (see > > "man 4 cam", option CAMDEBUG, and flags CAM_DEBUG_TRACE and > > CAM_DEBUG_SUBTRACE) and to capture all console output up to the hang > > (for example using a serial console) > > > >* if Scott's hunch of an interrupt storm is correct, then this issue > > might be related to the DMA problem described under PR 103602, so > > it would be useful to try the last patch I sent on that PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=103602&getpatch=12 > > > >* if all else fails, please let me know if the attached patch, which > > reverts part of rev. 1.42.2.3, changes anything. I've tried your patch on recent current with all CAM options, but no luck. I am still having a reboot on my notebook while trying to run k3b. No errors... no panic... just a reboot. > > > > I tried your attached patch and the problem is still the same. System hangs > when starts k3b. > With atapi-cam.c rev. 1.42.2.2, k3b starts fine, system doesn't hang. > > For your information I have k3b normal startup messages with atapi-cam.c rev. > 1.42.2.2. > It might help to find the problem. > > devil# k3b > Only one line in dcopserver file !: > DCOPClient::attachInternal. Attach failed networkIdsList argument is NULL > Only one line in dcopserver file !: > DCOPClient::attachInternal. Attach failed networkIdsList argument is NULL > kbuildsycoca running... > devil# kdecore (KAction): WARNING: KActionCollection::KActionCollection( > QObject *parent, const char *name, KInstance *instance ) > k3b: (K3bCdrecordProgram) could not start /opt/schily/bin > k3b: (K3bMkisofsProgram) could not start /opt/schily/bin > k3b: (K3bCdrecordProgram) could not start /root/bin > k3b: (K3bMkisofsProgram) could not start /root/bin > k3b: (K3bExternalBinManager) Cdrecord 2.1 features: gracetime, overburn, > cdtext, clone, tao, cuefile, xamix, plain-atapi, hacked-atapi, audio-stdin, > burnfree > k3b: (K3bExternalBinManager) 2 1 -1 seems to be cdrecord version >= 1.11a02, > using burnfree instead of burnproof > k3b: (K3bExternalBinManager) seems to be cdrecord version >= 1.11a31, support > for Just Link via burnfree driveroption > (BSDDeviceScan) number of matches 10 > (BSDDeviceScan) add device /dev/cd0:1:0:0 > (K3bDevice::Device) /dev/cd0: init() > (K3bDevice::openDevice) open device /dev/pass0 succeeded. > (K3bDevice::openDevice) open device /dev/pass0 succeeded. > (K3bDevice::ScsiCommand) transport command 12, length: 6 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: CD Mastering > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: CD Track At Once > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: CD-RW Media Write Support > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: DVD Read (MMC5) > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: DVD+R > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: DVD+RW > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: DVD+R Double Layer > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: DVD-R/-RW Write > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: Rigid Restricted Overwrite > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::openDevice) open device /dev/pass0 succeeded. > (K3bDevice::openDevice) open device /dev/pass0 succeeded. > (K3bDevice::ScsiCommand) transport command 5a, length: 10 > (K3bDevice::ScsiCommand) transport command 5a, length: 10 > (K3bDevice::D
Re: kern/112119: system hangs when starts k3b on RELENG_6
Thomas, I tried your patch at http://www.freebsd.org/cgi/query-pr.cgi?pr=103602&getpatch=12 and the problem is still the same. Ssytem freezes upon start of k3b. I also tried your attached patch, which reverts part of rev. 1.42.2.3 and the problem is still the same, system hangs when starts k3b. Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ASUS P5LD2-VM problem?
On Fri, Apr 27, 2007 at 04:50:53PM +0300, Andrei V. Lavreniyuk wrote: > Motherboard: > ASUS P5LD2-VM Socket775 BIOS version 1304 > > acpi_bus_number: can't get _ADR > acpi_bus_number: can't get _ADR > ?? Almost every system (workstation or server) i've seen which uses ACPI spits this out. I have no idea what it means, but it appears to be harmless. > acpi_throttle1: on cpu1 > acpi_throttle1: failed to attach P_CNT > ? > device_attach: acpi_throttle1 attach returned 6 My guess is that there's either some invalid ACPI data being given to FreeBSD via the BIOS (which would make this Asus's fault), or there needs to be a one-off/tweak added for ACPI throttling for this particular motherboard. You should really be sending all of this to the freebsd-acpi list. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: No longer need to recompile milters when upgrading
If memory serves me right, Gregory Shapiro wrote: > The libmilter ABI breakage which required recompiling mail filters > (milters) has been fixed in the RELENG_[456] branches. > > It is no longer necessary to recompile mail filters compiled against an > older libmilter.so shared library. Additionally, if you did recompile > them already, you do not need to recompile them again. Thanks for all your work on this! Bruce. signature.asc Description: OpenPGP digital signature
ASUS P5LD2-VM problem?
Hi! System: FreeBSD consulting 6.2-STABLE FreeBSD 6.2-STABLE #0: Fri Apr 27 00:46:01 EEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP-ECORYS i386 Motherboard: ASUS P5LD2-VM Socket775 BIOS version 1304 -- # dmesg Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-STABLE #0: Fri Apr 27 00:46:01 EEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP-ECORYS ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.37-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf49 Stepping = 9 Features=0xbfebfbff Features2=0x641d> AMD Features=0x2000 AMD Features2=0x1 Logical CPUs per core: 2 real memory = 528023552 (503 MB) avail memory = 506372096 (482 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR ?? acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT ? device_attach: acpi_throttle1 attach returned 6 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 2.0 (no driver attached) pcib1: irq 16 at device 28.0 on pci0 pci3: on pcib1 pcib2: irq 17 at device 28.1 on pci0 pci2: on pcib2 em0: port 0xd800-0xd81f mem 0xcffe-0xcfff irq 17 at device 0.0 on pci2 em0: Ethernet address: 00:17:31:54:5c:c4 pcib3: at device 30.0 on pci0 pci1: on pcib3 rl0: port 0xc400-0xc4ff mem 0xcfeff800-0xcfeff8ff irq 21 at device 9.0 on pci1 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:02:44:9e:22:f8 rl1: port 0xc800-0xc8ff mem 0xcfeffc00-0xcfeffcff irq 22 at device 10.0 on pci1 miibus1: on rl1 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:e0:7d:e5:6b:49 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0xb800-0xb807,0xb400-0xb403,0xb000-0xb007,0xa800-0xa803,0xa400-0xa40f irq 17 at device 31.2 on pci0 ata2: on atapci1 ata3: on atapci1 ichsmb0: port 0x400-0x41f at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] smbus0: on ichsmb0 smb0: on smbus0 acpi_button0: on acpi0 speaker0: port 0x61 on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 2000 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert enabled, rule-based forwarding enabled, default to deny, logging limited to 100 packets/entry by default acd0: DVDROM at ata0-master UDMA33 ad4: 152627MB at ata2-master SATA150 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a GEOM_ELI: Device ad4s1b.eli created. GEOM_ELI: Encryption: AES-CBC 256 GEOM_ELI: Crypto: software rl1: link state changed to UP - # pciconf -lv [EMAIL PROTECTED]:0:0:class=0x06 card=0x817a1043 chip=0x27708086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945 Series Memory Controller Hub (MCH)' class = bridge subclass = HOST-PCI [EMAIL PROTECTED]:2:0: class=0x03 card=0x817a1043 chip=0x27728086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Integrated Graphics Controller' class = display subclass = VGA [EMAIL PROTECTED]:28:0:class=0x060400 card=0x81791043 chip=0x27d08086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCI Express Root Port' class = bridge subclass = PCI-PCI [EMAIL PROTECTED]:28:1:class=0x060400 card=0x81791043 chip=0x27d28086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCI Express Root Port' class = bridge subclass = PCI-PCI [EMAIL PROTECTED]:30:0:class=0x060401 card=0x81791043 chip=0x244e8086 rev=0xe1 hdr=0x01 vendor = 'Intel Corporation' device = '82801BA/CA/DB/DBL/EB/ER/FB (ICH2/3/4/4/5/5/6), 6300ESB Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI [EMAIL PROTECTED]:31:0:class=0x060100 card=0x8179104
Re: xfce4 desktop broken, complaining about libmd5.so.1
On Friday 27 April 2007 20:48, Oliver Fromme wrote: > Oliver Fromme wrote: > > Just a small addendum _how_ to find it out: > > > > $ cd /usr/ports > > $ echo */*/pkg-plist | xargs grep libmd5.so.1 > > I'm very sorry for repeatedly replying to myself, but I > almost forgot that there's a much faster way to find the > port which has that library: > > http://www.secnetix.de/tools/porgle/ > > Enter "libmd5.so.1" into the search field, check the > "packing list" checkbox, and click the "Search" button. I suspect both of these methods wouldn't help if the plist was dynamically generated (alas) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgprc6ZwiPwGj.pgp Description: PGP signature
Re: CARP and em0 timeout watchdog
On Fri, 2007-04-20 at 14:44 -0400, Sven Willenberger wrote:
> On Fri, 2007-04-20 at 11:27 -0700, Jack Vogel wrote:
> > On 4/20/07, Sven Willenberger <[EMAIL PROTECTED]> wrote:
> > > On Fri, 2007-04-20 at 10:17 -0700, Jack Vogel wrote:
> > > > On 4/20/07, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> > > > > On Fri, Apr 20, 2007 at 11:51:56AM -0400, Sven Willenberger wrote:
> > > > > > Having done more diagnostics I have found out it is not CARP
> > > > > > related at
> > > > > > all. It turns out that the same timeouts will happen when ftp'ing
> > > > > > to the
> > > > > > physical address IPs as well. There is also an odd situation here
> > > > > > depending on which protocol I use. The two boxes are connected to a
> > > > > > Dell
> > > > > > Powerconnect 2616 gig switch with CAT6. If I scp files from the
> > > > > > 192.168.0.18 to the 192.168.0.19 box I can transfer gigs worth
> > > > > > without a
> > > > > > hiccup (I used dd to create various sized testfiles from 32M to 1G
> > > > > > in
> > > > > > size and just scp testfile* to the other box). On the other hand,
> > > > > > if I
> > > > > > connect to 192.168.0.19 using ftp (either active or passive) where
> > > > > > ftp
> > > > > > is being run through inetd, the interface resets (watchdog) within
> > > > > > seconds (a few MBs) of traffic. Enabling polling does nothing, nor
> > > > > > does
> > > > > > changing net.inet.tcp.{recv,send}space. Any ideas why I would be
> > > > > > seeing
> > > > > > such behavioral differences between scp and ftp?
> > > > >
> > > > > You'll get a much higher throughput rate with FTP than you will with
> > > > > SSH, simply because encryption overhead is quite high (even with the
> > > > > Blowfish cipher). With a very fast processor and on a gigE network
> > > > > you'll probably see 8-9MByte/sec via SSH while 60-70MByte/sec via FTP.
> > > > > That's the only difference I can think of.
> > > > >
> > > > > The watchdog resets I can't explain; Jack Vogel should be able to
> > > > > assist
> > > > > with that. But it sounds like the resets only happen under very high
> > > > > throughput conditions (which is why you'd see it with FTP but not
> > > > > SSH).
> > > >
> > > > What kind of hardware is this interface? Watchdogs mean TX cleanup
> > > > isn't happening in a reasonable time, without further data its hard to
> > > > know what might be going on.
> > > >
> > > > Jack
> > >
> > > from pciconf:
> > >
> > > [EMAIL PROTECTED]:0:0: class=0x02 card=0x108c15d9 chip=0x108c8086
> > > rev=0x03
> > > hdr=0x00
> > > vendor = 'Intel Corporation'
> > > device = 'PRO/1000 PM'
> > > class= network
> > > subclass = ethernet
> > > [EMAIL PROTECTED]:0:0: class=0x02 card=0x109a15d9 chip=0x109a8086
> > > rev=0x00
> > > hdr=0x00
> > > vendor = 'Intel Corporation'
> > > class= network
> > > subclass = ethernet
> > >
> > > em0 is the interface in question.
> > >
> > > from dmesg:
> > >
> > > em0: port
> > > 0x4000-0x401f mem 0xe030-0xe031 irq 16 at device 0.0 on pci13
> > >
> > > em1: port
> > > 0x5000-0x501f mem 0xe040-0xe041 irq 17 at device 0.0 on pci14
> >
> > OH, this is an 82573, and I've posted a firmware patcher a couple
> > different times, there is a bit in the MANC register that is incorrectly
> > programmed in some vendors systems. Can you search email for
> > that patcher, it needs to run from DOS. If you are unable to find
> > it let me know and I'll resent you a copy.
> >
> > Jack
>
> If you are referring to the dcgdis.ThisIsZip attachment, I found it in
> earlier threads, thanks. Will work on patching the nics and will keep
> the list updated.
>
> Thanks again.
>
> Sven
>
I am happy to report that the firmware patch seems to have fixed the
issue and I can transfer data across the gigE network without the
watchdog timeouts and lockups. Thanks again!!
Sven
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: xfce4 desktop broken, complaining about libmd5.so.1
Oliver Fromme wrote: > Just a small addendum _how_ to find it out: > > $ cd /usr/ports > $ echo */*/pkg-plist | xargs grep libmd5.so.1 I'm very sorry for repeatedly replying to myself, but I almost forgot that there's a much faster way to find the port which has that library: http://www.secnetix.de/tools/porgle/ Enter "libmd5.so.1" into the search field, check the "packing list" checkbox, and click the "Search" button. 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 "Being really good at C++ is like being really good at using rocks to sharpen sticks." -- Thant Tessman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: xfce4 desktop broken, complaining about libmd5.so.1
Oliver Fromme wrote: > Chris Rees <[EMAIL PROTECTED]> wrote: > > Kind of embarrassing, I'm running 6.2-STABLE, and I recently used > > pkg_cutleaves to free some disk space. However, xfce's desktop doesn't work > > any more, neither will Thunar, and they both complain about missing file > > /usr/local/lib/libmd5.so.1. My locate database says it was there before I > > deinstalled all those packages, but I can't work out which ones I got rid > > of, nor which package libmd5.so.1 came from > > > > Could anyone please help me out? > > Install /usr/ports/www/libwww. Just a small addendum _how_ to find it out: $ cd /usr/ports $ echo */*/pkg-plist | xargs grep libmd5.so.1 (That approach works for most ports and files, but not for all of them. Some ports generate their packing list (plist) dynamically, but fortunately those are a small minority.) 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 "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]"
Re: xfce4 desktop broken, complaining about libmd5.so.1
Chris Rees <[EMAIL PROTECTED]> wrote: > Kind of embarrassing, I'm running 6.2-STABLE, and I recently used > pkg_cutleaves to free some disk space. However, xfce's desktop doesn't work > any more, neither will Thunar, and they both complain about missing file > /usr/local/lib/libmd5.so.1. My locate database says it was there before I > deinstalled all those packages, but I can't work out which ones I got rid > of, nor which package libmd5.so.1 came from > > Could anyone please help me out? Install /usr/ports/www/libwww. 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 "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]"
xfce4 desktop broken, complaining about libmd5.so.1
Kind of embarrassing, I'm running 6.2-STABLE, and I recently used pkg_cutleaves to free some disk space. However, xfce's desktop doesn't work any more, neither will Thunar, and they both complain about missing file /usr/local/lib/libmd5.so.1. My locate database says it was there before I deinstalled all those packages, but I can't work out which ones I got rid of, nor which package libmd5.so.1 came from Could anyone please help me out? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
