Free memory after upgrade to 7.1
Hello, I have i386/PAE system (php, apache22, mysql) running on 7-STABLE and I can see strange behavior after upgrade from 7.0: Apache does not free memory, for example: CPU: 31.2% user, 0.0% nice, 12.8% system, 0.7% interrupt, 55.3% idle Mem: 3520M Active, 3705M Inact, 465M Wired, 314M Cache, 112M Buf, 12M Free Swap: 4096M Total, 105M Used, 3991M Free, 2% Inuse then apachectl graceful CPU: 28.3% user, 0.0% nice, 8.6% system, 0.0% interrupt, 63.1% idle Mem: 631M Active, 3126M Inact, 353M Wired, 213M Cache, 112M Buf, 3693M Free Swap: 4096M Total, 1844K Used, 4094M Free Some graph: http://max.af.czu.cz/memoryload.png I know before upgrade was memory using about 2,5GB, now much more, apache sometimes crash. Thanks for some help Tomas Randa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Free memory after upgrade to 7.1
Yes, I do portupgrade -Rrfia after upgrade of course. I don`t think it is some new PHP bug, because my friend have same problem with memory and he do not upgraded ports. But his box do not free memory after apache reload, my yes Any other suggestions ? Thanks TR Tom Evans napsal(a): On Wed, 2009-02-04 at 17:08 +0100, Tomas Randa wrote: Hello, I have i386/PAE system (php, apache22, mysql) running on 7-STABLE and I can see strange behavior after upgrade from 7.0: Apache does not free memory, for example: CPU: 31.2% user, 0.0% nice, 12.8% system, 0.7% interrupt, 55.3% idle Mem: 3520M Active, 3705M Inact, 465M Wired, 314M Cache, 112M Buf, 12M Free Swap: 4096M Total, 105M Used, 3991M Free, 2% Inuse then apachectl graceful CPU: 28.3% user, 0.0% nice, 8.6% system, 0.0% interrupt, 63.1% idle Mem: 631M Active, 3126M Inact, 353M Wired, 213M Cache, 112M Buf, 3693M Free Swap: 4096M Total, 1844K Used, 4094M Free Some graph: http://max.af.czu.cz/memoryload.png I know before upgrade was memory using about 2,5GB, now much more, apache sometimes crash. Thanks for some help Tomas Randa What is apache doing to use so much memory? This looks more like a memory leak in PHP, which is reclaimed after apache restarts its children. When you upgraded the OS, did you also upgrade ports? Could a new version of PHP be at fault here? Cheers Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Big problems with 7.1 locking up :-(
Hello, I have similar problems. The last good kernel I have from stable brach, october the 8. Then in next upgrade, I saw big problems with performance. I tried ULE, 4BSD etc, but nothing helps, only downgrading system back. Now I am trying 7.1-p1 and problems are here again. Mysql is waiting a lot of time with status waiting for opening table or waiting for close tables I have 32bit FreeBSD with PAE, 1x xeon 5420, supermicro motherboard, areca SATA controller. Could not be problem in da device for example? Thanks Tomas Randa Garance A Drosihn wrote: At 2:55 PM + 1/12/09, Robert Watson wrote: On Fri, 9 Jan 2009, Garance A Drosihn wrote: At 2:39 PM -0500 1/9/09, Robert Blayzor wrote: On Jan 8, 2009, at 8:58 PM, Pete French wrote: I have a number of HP 1U servers, all of which were running 7.0 perfectly happily. I have been testing 7.1 in it's various incarnations for the last couple of months on our test server and it has performed perfectly. I noticed a problem with 7.0 on a couple of Dell servers. [...] We've since then compiled the kernel under the BSD scheduler to rule that out, and so far so good. Since ULE is now default in 7.1 and not in 7.0, perhaps you can try that? FWIW, the other guy I know who is having this problem had already switched to using ULE under 7.0-release, and did not have any problems with it. So *his* problem was probably not related to SCHED_ULE, unless something has recently changed there. Turns out he hasn't reverted back to 7.0-release just yet, so he's going to try SCHED_4BSD and see if that helps his situation. Scheduler changes always come with some risk of exposing bugs that have existed in the code for a long time but never really manifested themselves. ULE is well shaken-out, having been under development for at least five years, but it is possible that some problems will become visible as a result of the switch. I would encourage people to stick with ULE, but if you're having a stability problem then experimenting with scheduler as a variable that could be triggering the problem may well be useful to help track down the bug. Just to followup on this: My friend did switch back to a 7.1 kernel with SCHED_4BSD, and he still ran into problems. The error messages weren't the same, but errors did happen in the same high disk-I/O situations as the lockup happened with SCHED_ULE. At this point he's fallen back to the 7.0-kernel that he had been running (which also has SCHED_ULE), and all the problems have gone away. So at the moment he's running with a 7.0-ish kernel and the 7.1-release userland, without the hanging problems. So the problem is something in the kernel, but it is *NOT* the scheduler (at least, not in his case). He is not eager to do a whole lot of experiments to track down the problem, since this is happening on busy production machines and he can't afford to have a lot of downtime on them (especially now that the semester at RPI has started up). The systems have some large (2 TB) filesystems on them, and the lockups occur in high disk-I/O situations. He's seeing the problem on one system which is a dual CPU quad-core xeon, and another which is a 64 bit P4 with hyperthreading. The one thing in common between the two setups is that the boot drives + a 3ware controller (with its array of RAID disks) is moved from one machine to the other one: its a 3ware 9500 12 port model, the boot drive is connected to an ICH6 in IDE mode, and yes, I've run it in single, single with hyper threading, and 8 way mode. All 64 bit. We still have no idea where the problem really is. For all we know, someone spilled a Pepsi on it when he wasn't looking... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
HT1000 serial ATA support
Hello everybody, I bought very nice motherboard SuperMicro H8SSL-i, but onboard serial ATA is supported in FreeBSD 6.0 as Generic, so only UDMA33 is possible. I would ask here, what I can do for making this device fully functional on full speed. Thank a lot Tomas Randa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ServerWorks HT1000 experience?
Hello! I would buy new SuperMicro motherboard H8SSL-i / http://www.supermicro.com/Aplus/motherboard/Opteron/HT1000/H8SSL-i.cfm / based on ServerWorks HT1000 Chipset. Is anybody here who tested these new chipsets HT1000 / HT2000 with FreeBSD ? Thanks for your answers. Tomas Randa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Strange SATA problem - data corrupting
Hello, I have very strange problem with my FreeBSD box and Promise PDC20579 SATA controller: [EMAIL PROTECTED]:7:0: class=0x010400 card=0x3574105a chip=0x3574105a rev=0x02 hdr=0x00 vendor = 'Promise Technology Inc' device = 'Promise SATAII150 579 (tm) IDE Controller' class= mass storage subclass = RAID ad4: 381554MB ST3400832AS/3.02 [775221/16/63] at ata2-master SATA150 Problem is, that every HDD connected to this controller is corrupting data. For example: I copy good tar.gz archive to this drive, and if I do decompression immediately after copying, there is no problem, but if I wait for example 10 minutes, then decompression ends with CRC error: box# gzip -d ./2005-09-11.tar.gz gzip: ./2005-09-11.tar.gz: invalid compressed data--crc error gzip: ./2005-09-11.tar.gz: invalid compressed data--length error I know, that problem is not in HDD or CPU/RAM, but in controller. Could it be a driver problem or not? I tried to turn off soft-updates, but with no change. I have no any ideas what to do or what to try. Thanks a lot for any answer or opinion. Tomas Randa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange SATA problem - data corrupting
Thanks for quick answer. I think I am sure, because if I connect this hard drive from this onboard Promise controller with same cable to onboard VIA8237 it works well. I tried other HDD - 76319MB ST380817AS/3.42 [155061/16/63] at ata5-master SATA150 not with same cable, I had exactly the same problem. FreeBSD box.freebsd 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #0: Wed Aug 31 00:09:53 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/18BOX i386 My BOX has Soltek SL-K890PRO-939 with onboard integrated this Promise RAID Dmesg in attachement. Now I am looking for this in dmesg: atapci0: failed: rid 0x20 is memory, requested 4 atapci0: Promise PDC20579 SATA150 controller port 0xc000-0xc0ff,0xdf00-0xdf7f mem 0xdc0c-0xdc0d,0xdc0e6000-0xdc0e6fff irq 19 at device 7.0 on pci0 atapci0: failed: rid 0x20 is memory, requested 4 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 ata4: channel #2 on atapci0 Tomas Randa pete wright wrote: On 9/12/05, *Tomas Randa* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello, I have very strange problem with my FreeBSD box and Promise PDC20579 SATA controller: [EMAIL PROTECTED]:7:0: class=0x010400 card=0x3574105a chip=0x3574105a rev=0x02 hdr=0x00 vendor = 'Promise Technology Inc' device = 'Promise SATAII150 579 (tm) IDE Controller' class= mass storage subclass = RAID ad4: 381554MB ST3400832AS/3.02 [775221/16/63] at ata2-master SATA150 Problem is, that every HDD connected to this controller is corrupting data. For example: I copy good tar.gz archive to this drive, and if I do decompression immediately after copying, there is no problem, but if I wait for example 10 minutes, then decompression ends with CRC error: box# gzip -d ./2005-09-11.tar.gz gzip: ./2005-09-11.tar.gz: invalid compressed data--crc error gzip: ./2005-09-11.tar.gz: invalid compressed data--length error I know, that problem is not in HDD or CPU/RAM, but in controller. Could it be a driver problem or not? I tried to turn off soft-updates, but with no change. I have no any ideas what to do or what to try. Thanks a lot for any answer or opinion. Are you sure that it is not an issue with the drives? Just to make sure, you have attached these drives to another, known working system and seen the same issues. Also, have you made sure that the cabling to the drives themselves are not broken, and are seated properlly. To be sure, I'd grab a set of working sata cables and test out again. Finally, if you have done this hardware trouble shooting already and are sure that it is not a hardware issue with your disks/cabling/controller itself I would post the version of FreeBSD you are running (uname -ar) along with a dmesg to the list. -p -- ~~o0OO0o~~ Pete Wright www.nycbug.org http://www.nycbug.org NYC's *BSD User Group Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE-p6 #0: Wed Aug 31 00:09:53 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/18SHINZON module_register: module pci/em already exists! Module pci/em failed to register: 17 ACPI APIC Table: K8T890 AWRDACPI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3500+ (2199.76-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x20ff0 Stepping = 0 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 AMD Features=0xe050NX,AMIE,LM,DSP,3DNow! real memory = 3220045824 (3070 MB) avail memory = 3153993728 (3007 MB) ioapic0 Version 0.3 irqs 0-23 on motherboard ioapic1 Version 0.3 irqs 24-47 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: K8T890 AWRDACPI on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR 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
ahd0: Adaptec 29320 Ultra320 SCSI adapter
Hello, my FreeBSD 5.4 box with gives me strange messages concerning Adaptec SCSI adapter 29320 (ahd): ahd1: WARNING no command for scb 0 (cmdcmplt) QOUTPOS = 277 Dump Card State Begins ahd1: Dumping Card State at program address 0x82 Mode 0x22 Completions are pending INTSTAT[0x0] SELOID[0x0] SELID[0x0] HS_MAILBOX[0x0] INTCTL[0xc0]:(SWTMINTEN|SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11] DFFSTAT[0x31]:(CURRFIFO_1|FIFO0FREE|FIFO1FREE) SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x10]:(FASTMODE) SEQINTCTL[0x0] SEQ_FLAGS[0xc0]:(NO_CDB_SENT|NOT_IDENTIFIED) SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x51] KERNEL_QFREEZE_COUNT[0x51] MK_MESSAGE_SCB[0x3e] MK_MESSAGE_SCSIID[0x7] SSTAT0[0x0] SSTAT1[0x8]:(BUSFREE) SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0] SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] On the end of message there are lines like (da0:ahd1:0:0:0): SCB 8 - timed out (da0:ahd1:0:0:0): Queuing a BDR SCB (da0:ahd1:0:0:0): Bus Device Reset Message Sent (da0:ahd1:0:0:0): no longer in timeout, status = 24b ahd1: Bus Device Reset on A:0. 1 SCBs aborted (da0:ahd1:0:0:0): READ(10). CDB: 28 0 0 e1 2d 8b 0 0 8 0 (da0:ahd1:0:0:0): CAM Status: SCSI Status Error (da0:ahd1:0:0:0): SCSI Status: Check Condition (da0:ahd1:0:0:0): UNIT ATTENTION asc:29,3 (da0:ahd1:0:0:0): Bus device reset function occurred field replaceable unit: 4 (da0:ahd1:0:0:0): Retrying Command (per Sense Data) Could it be problem with this Seagate ST336754LW? I have firmware 003 in this drive from Seagate, about 2 months old, but problem persist. Is this a drive problem or controller problem? I read messages from Robert and his problems with Adaptec 39320 and DELL SC430, so i tried command camcontrol tags da0 -N 32, but no change. Thanks for help. Complete dmesg and messages included. Tomas Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE-p4 #0: Fri Jul 8 01:35:23 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BOX ACPI APIC Table: K8T890 AWRDACPI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3500+ (2199.76-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x20ff0 Stepping = 0 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 AMD Features=0xe050NX,AMIE,LM,DSP,3DNow! real memory = 3220045824 (3070 MB) avail memory = 3154006016 (3007 MB) ioapic0 Version 0.3 irqs 0-23 on motherboard ioapic1 Version 0.3 irqs 24-47 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: K8T890 AWRDACPI on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR 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 0x4008-0x400b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: base peripheral, interrupt controller at device 0.5 (no driver attached) pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 27 at device 2.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 3.0 on pci0 pci3: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge irq 35 at device 3.1 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge irq 39 at device 3.2 on pci0 pci5: ACPI PCI bus on pcib5 pcib6: ACPI PCI-PCI bridge irq 43 at device 3.3 on pci0 pci6: ACPI PCI bus on pcib6 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xea00-0xea3f mem 0xdc08-0xdc09,0xdc0a-0xdc0b irq 16 at device 8.0 on pci0 em0: Ethernet address: 00:07:e9:01:61:fc em0: Speed:N/A Duplex:N/A ahd0: Adaptec 29320 Ultra320 SCSI adapter port
Re: SCSI troubles still
Hi, thanks for your answer. I have U320 cable with active terminator on its and. But I could try some other cable. Thanks for idea. Tomas Randa David Vastine wrote: On Jul 10, 2005, at 3:51 PM, Tomas Randa wrote: Hi all, I am writing you again because I have still problems with my FreeBSD BOX (5.4 p4) with AHD and Seagate 15k4 drive. System is based on Via K8T890 / Athlon64, i386 distribution of FreeBSD. I have *latest firmware* in drive and controller ( ST336754LW 003 and Adaptec 29320 4.30.0), but still have sometime problems like this on console: When this dumping start, my system have a huge load - about 150! I have no idea what to do next, please help someone. Is Ultra320 from Seagate broken? Should I try to slow down the disk bus speed to 160MB/s ? Thanks! Tomas Randa Is the drive properly terminated? When I got errors like those it was due to the drive not being terminated.. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
SCSI troubles still
Hi all, I am writing you again because I have still problems with my FreeBSD BOX (5.4 p4) with AHD and Seagate 15k4 drive. System is based on Via K8T890 / Athlon64, i386 distribution of FreeBSD. I have *latest firmware* in drive and controller ( ST336754LW 003 and Adaptec 29320 4.30.0), but still have sometime problems like this on console: When this dumping start, my system have a huge load - about 150! I have no idea what to do next, please help someone. Is Ultra320 from Seagate broken? Should I try to slow down the disk bus speed to 160MB/s ? Thanks! Tomas Randa Dump Card State Begins ahd1: Dumping Card State at program address 0xa8 Mode 0x33 Completions are pending INTSTAT[0x2]:(CMDCMPLT) SELOID[0x0] SELID[0x0] HS_MAILBOX[0x0] INTCTL[0xc0]:(SWTMINTEN|SWTMINTMASK) SEQINTSTAT[0x10]:(SEQ_SWTMRTO) SAVED_MODE[0x11] DFFSTAT[0x11]:(CURRFIFO_1|FIFO0FREE) SCSISIGI[0x24]:(P_DATAOUT_DT|BSYI) SCSIPHASE[0x1]:(DATA_OUT_PHASE) SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x10]:(FASTMODE) SEQINTCTL[0x10]:(SCS_SEQ_INT1M1) SEQ_FLAGS[0xc0]:(NO_CDB_SENT|NOT_IDENTIFIED) SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x1f] KERNEL_QFREEZE_COUNT[0x1f] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x19]:(REQINIT|BUSFREE|PHASEMIS) SSTAT2[0x0] SSTAT3[0x80] PERRDIAG[0x0] SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x81]:(LQOSTOP0) SCB Count = 224 CMDS_PENDING = 15 LASTSCB 0x14 CURRSCB 0x14 NEXTSCB 0xff00 qinstart = 22356 qinfifonext = 22356 QINFIFO: WAITING_TID_QUEUES: Pending list: 20 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 18 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 46 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 47 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 49 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 26 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 13 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 32 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 38 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 61 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 55 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 9 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 31 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 58 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 44 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 24 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] 51 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] 29 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] 4 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] 60 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] 59 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] 37 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] 28 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] 79 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] 35 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] 12 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] 22 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 53 FIFO_USE[0x0] SCB_CONTROL[0x68]:(STATUS_RCVD|TAG_ENB|DISCENB) SCB_SCSIID[0x7] 34 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] 5 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] 45 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] 36 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] Total 32 Kernel Free SCB list: 40 30 19 21 56 6 48 16 23 17 63 54 8 27 62 39 52 42 25 43 57 0 50 2 33 14 41 10 3 7 15 11 1 78 72 73 74 75 76 77 220 221 222 223 192 193 194 195 196 197 198 199 200 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: Sequencer On QFreeze and Complete list: ahd1: FIFO0 Free, LONGJMP == 0x8295, SCB 0x31 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x7e] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x0] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCSI troubles
Hi, I tried ahc controller, but with ahd (29320 controller) the situation is identical :( I have a database server data and system on this hard drive. And for example when I start cvsup or copy big files, this errors starts. Somewhere on google, I read that problems might be when Tagged Queing is enabled, do you think it is possible? Thanks Tomas Randa Bruce Burden wrote: On Mon, Jun 20, 2005 at 12:10:27AM +0200, Tomas Randa wrote: I Am running 5.4-STABLE FreeBSD 5.4-STABLE #0: Sun May 8 18:23:40 CEST 2005 with Adaptec 29320 or 2930U2 controller and with heavy load on SCSI I have the following problems ending with system freeze. Have anybody some opinion where could be problem? kernel: ahc0: WARNING no command for scb 0 (cmdcmplt) kernel: QOUTPOS = 252 Why are you using ahc() rather than ahd()? Have you tried the ahd() driver previously? What do you consider heavy load? I have nad no problems with the ahd() and a 29320. Bruce ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
SCSI troubles
Hi, I Am running 5.4-STABLE FreeBSD 5.4-STABLE #0: Sun May 8 18:23:40 CEST 2005 with Adaptec 29320 or 2930U2 controller and with heavy load on SCSI I have the following problems ending with system freeze. Have anybody some opinion where could be problem? Thanks a lot Tomas Randa da0: SEAGATE ST336754LW 0002 Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled kernel: ahc0: WARNING no command for scb 0 (cmdcmplt) kernel: QOUTPOS = 252 kernel: ahc0: WARNING no command for scb 0 (cmdcmplt) kernel: QOUTPOS = 253 kernel: ahc0: WARNING no command for scb 0 (cmdcmplt) kernel: QOUTPOS = 254 kernel: ahc0: WARNING no command for scb 0 (cmdcmplt) kernel: QOUTPOS = 255 kernel: ahc0: Recovery Initiated kernel: Dump Card State Begins kernel: ahc0: Dumping Card State while idle, at SEQADDR 0x8 kernel: Card was paused kernel: ACCUM = 0x0, SINDEX = 0x7, DINDEX = 0xe4, ARG_2 = 0x0 kernel: HCNT = 0x0 SCBPTR = 0xa kernel: SCSISIGI[0x0] ERROR[0x0] SCSIBUSL[0x0] LASTPHASE[0x1]:(P_BUSFREE) kernel: SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) SBLKCTL[0xa]:(SELWIDE|SELBUSB) kernel: SCSIRATE[0x0] SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0xc0]:(NO_CDB_SENT|NOT_IDENTIFIED kernel: SSTAT0[0x0] SSTAT1[0xa]:(PHASECHG|BUSFREE) SSTAT2[0x0] kernel: SSTAT3[0x0] SIMODE0[0x8]:(ENSWRAP) SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) kernel: SXFRCTL0[0x80]:(DFON) DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) kernel: STACK: 0x0 0x167 0x10d 0x3 kernel: SCB count = 70 kernel: Kernel NEXTQSCB = 43 kernel: Card NEXTQSCB = 43 kernel: QINFIFO entries: kernel: Waiting Queue entries: kernel: Disconnected Queue entries: kernel: QOUTFIFO entries: kernel: Sequencer Free SCB List: 10 0 20 23 12 15 19 29 18 28 26 7 5 27 9 17 30 1 2 16 4 kernel: Sequencer SCB Info: kernel: 0 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] kernel: SCB_LUN[0x0] SCB_TAG[0xff] kernel: 1 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] kernel: SCB_LUN[0x0] SCB_TAG[0xff] kernel: 2 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] kernel: SCB_LUN[0x0] SCB_TAG[0xff] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
