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]
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]
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
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: 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: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port
0x4000-0x401f mem 0xe030-0xe031 irq 16 at device 0.0 on pci13
em1: Intel(R) PRO/1000 Network Connection Version - 6.2.9 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
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
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: A_M_I_ OEMAPIC 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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x641dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,b14 AMD Features=0x2000LM AMD Features2=0x1LAHF 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 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: NEC 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: ACPI CPU on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 cpu1: ACPI CPU on acpi0 acpi_throttle1: ACPI CPU Throttling on cpu1 acpi_throttle1: failed to attach P_CNT ? device_attach: acpi_throttle1 attach returned 6 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: display, VGA at device 2.0 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci3: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 17 at device 28.1 on pci0 pci2: ACPI PCI bus on pcib2 em0: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0xd800-0xd81f mem 0xcffe-0xcfff irq 17 at device 0.0 on pci2 em0: Ethernet address: 00:17:31:54:5c:c4 pcib3: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib3 rl0: RealTek 8139 10/100BaseTX port 0xc400-0xc4ff mem 0xcfeff800-0xcfeff8ff irq 21 at device 9.0 on pci1 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:02:44:9e:22:f8 rl1: RealTek 8139 10/100BaseTX port 0xc800-0xc8ff mem 0xcfeffc00-0xcfeffcff irq 22 at device 10.0 on pci1 miibus1: MII bus on rl1 rlphy1: RealTek internal media interface on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:e0:7d:e5:6b:49 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH7 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 atapci1: Intel ICH7 SATA300 controller port 0xb800-0xb807,0xb400-0xb403,0xb000-0xb007,0xa800-0xa803,0xa400-0xa40f irq 17 at device 31.2 on pci0 ata2: ATA channel 0 on atapci1 ata3: ATA channel 1 on atapci1 ichsmb0: SMBus controller port 0x400-0x41f at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] smbus0: System Management Bus on ichsmb0 smb0: SMBus generic I/O on smbus0 acpi_button0: Power Button on acpi0 speaker0: PC speaker port 0x61 on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 2000 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA 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 HL-DT-STDVD-ROM GDR8164B/0L06 at ata0-master UDMA33 ad4: 152627MB WDC WD1600AAJS-00PSA0 05.06H05 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'
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
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: ACPI CPU Throttling 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: 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=103602getpatch=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: 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=103602getpatch=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::Device) /dev/cd0: dataLen: 60 (K3bDevice::Device) /dev/cd0: checking for TAO (K3bDevice::ScsiCommand) transport command 55, length: 10
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=103602getpatch=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: 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: 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
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: 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=103602getpatch=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: 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=104406cat= 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: user1 my system hangs/panics/etc user2 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
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=103602getpatch=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. What really needs to happen if for ATA to have an
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
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: 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: 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?)
-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
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: 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: 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
