Re: FreeBSD Quarterly Status Report - Fourth Quarter 2016
On 14.02.2017 05:20 Benjamin Kaduk wrote: > Core requested the removal of the misc/jive port, on the grounds that >it had no function other than to turn text into an offensively racist >parody. This proved controversial, with many seeing this as a first >step in bowdlerizing the entire ports tree. That is certainly not >Core's intention. Core's aim here is to help secure the future of the >FreeBSD project by making it welcoming to all contributors, regardless >of ethnicity, gender, sexuality or other improper bases for >discrimintation. While misc/jive may once have been seen as harmless >fun, today the implicit approval implied by having it in the ports tree >sends a message at odds with the project's aims. Am I dreaming? Has this "disease" finally reached my beloved FreeBSD after all this years? In my opinion it is just not Cores business making decisions besides the technical and organizational aspect. As long as any port has a handful of users and someone is willing to support it, its existence in the tree is justified. And basically I don't care if there is a port in the tree, where little harmless kittens are being shot at. Thank you Core! You made my day! K. signature.asc Description: OpenPGP digital signature
Re: LSI SAS2008 mps driver preferred firmware version
On 12.11.2015 23:20 Royce Williams wrote: > Firmware should match driver, e.g.: > > mps0: Firmware: 19.00.00.00, Driver: 19.00.00.00-fbs > > > Some of this may help -- not yet updated for 10.2, but may still be useful: > > http://roycebits.blogspot.com/2015/01/freebsd-lsi-sas9211-8i-hba-firmware.html Thanks! Lots of information about reflashing the 9211-8i. So I upgraded the old firmare of the controller from mps0: Firmware: 05.00.17.00, Driver: 20.00.00.00-fbsd to mps0: Firmware: 20.00.04.00, Driver: 20.00.00.00-fbsd (FreeBSD 10.2) As I understand it the firmware 20.00.00.00 was pulled by avago and replaced with the fixed version 20.00.04.00 I will give feedback if I notice any problems with this FW version. As a side note: Flashing the 9211-8i to the new firmware version changed the way FreeBSD orders the disk devices on this server: With the old firmware it looked like this: root@:~ # camcontrol devlist at scbus0 target 10 lun 0 (pass0,da0) at scbus0 target 11 lun 0 (pass1,da1) at scbus0 target 12 lun 0 (pass2,da2) at scbus0 target 13 lun 0 (pass3,da3) at scbus0 target 14 lun 0 (pass4,da4) at scbus0 target 15 lun 0 (pass5,da5) at scbus0 target 16 lun 0 (pass6,da6) at scbus0 target 17 lun 0 (pass7,da7) at scbus0 target 18 lun 0 (pass8,da8) at scbus0 target 19 lun 0 (pass9,da9) at scbus0 target 20 lun 0 (pass10,da10) at scbus0 target 21 lun 0 (pass11,da11) at scbus0 target 22 lun 0 (pass12,ses0) at scbus7 target 0 lun 0 (pass13,ses1) The order is according to the order the disks are placed in the drive bays: (da0, bay1; da1, bay2, ..) With the new firmware it now looks like this: at scbus0 target 8 lun 0 (pass0,da0) at scbus0 target 9 lun 0 (pass1,da1) at scbus0 target 10 lun 0 (pass2,da2) at scbus0 target 11 lun 0 (pass3,da3) at scbus0 target 12 lun 0 (pass4,da4) at scbus0 target 13 lun 0 (pass5,da5) at scbus0 target 14 lun 0 (pass6,da6) at scbus0 target 15 lun 0 (pass7,da7) at scbus0 target 16 lun 0 (pass8,da8) at scbus0 target 17 lun 0 (pass9,da9) at scbus0 target 18 lun 0 (pass10,da10) at scbus0 target 19 lun 0 (pass11,da11) at scbus0 target 20 lun 0 (pass12,ses0) at scbus7 target 0 lun 0 (pass13,ses1) So now the drive stuck in the last drive bay is seen as da0 and the drive in the first drive bay as da11 But: In the controller BIOS the scan order of the drives did not change at all with the new firmware! So the change is only in the way FreeBSD sees the drives. My explanation for this change in drive ordering is, that my 9211-8i is a SUN branded one (SGX-SAS6-INT-Z) and the server is a SUN server. So maybe the original firmware contained some adaptations for this server, that are missing in the new firmware. Can the way FreeBSD orders scanned SAS drives be changed? If not, no problem, as I use partition labels for my zfs pools and the disks are also labeled on the server as well. Regards, Kai. -- PGP-KeyID = 0x70654D7C4FB1F588 One day a lemming will fly.. signature.asc Description: OpenPGP digital signature
LSI SAS2008 mps driver preferred firmware version
Hi. I'm currently building a new ZFS based FreeBSD 10.2 server with a SAS/SATA HBA SAS9211-8i. Is there a preferred or recommended firmware version for Fusion-MPT SAS-2 2008 chipset based LSI cards like the SAS9211-8i? MPS(4) does not give any information about this. The current version of my SAS9211-8i is: v7.05.05.00 (2010.05.19), BIOS 5.00.17.00-IR, FW IR vs. IT firmware: Are there any advantages replacing the -IR (integrated raid) firmware on the LSI controller with an -IT (target mode) version, if the RAID functionality of the HBA is not used at all? There were some claims that running the -IR version in a ZFS JBOD setup would result in a small performance penalty compared to -IT and that there was a risk that a controller running the -IR firmware version could potentially damage ZFS data on a disk by putting RAID metadata somewhere on the drive, even if not using the RAID feature of the card! I'd appreciate it if someone could shed some light on this. Regards, Kai. -- PGP-KeyID = 0x70654D7C4FB1F588 One day a lemming will fly.. signature.asc Description: OpenPGP digital signature
FreeBSD 10.1-RELENG - No serial console on Intel J1900
Hi list. For some time I have been struggling to get the serial console operational on an ASRock Q1900B-ITX mainboard (Intel J1900) I have "-Dh" in /boot.config and tried enabling ttyu0 and ttyu1 in /etc/ttys. Serial cable was connected to the onboads serial ports of the mainboard. What I also tried was connecting the serial console cable to a USB to serial converter (using ttyU0 device in /etc/ttys), but also no luck. When I press return on an active console session the cursor on the console does a carriage return to the next line, but the screen shows no output at all. This can be seen on the USB to serial converter cable connection and also on the connection to the serial ports on the mainboard. I also made a test with kern.vty=vt console="comconsole vidconsole" comconsole_speed="9600" boot_multicons="YES" in /boot/loader.conf - but no solution. Is this ACPI related? Any hint appreciated. Regards, K. --- pciconf -lv --- % pciconf -lv hostb0@pci0:0:0:0: class=0x06 card=0x0f311849 chip=0x0f008086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView SSA-CUnit' class = bridge subclass = HOST-PCI vgapci0@pci0:0:2:0: class=0x03 card=0x0f311849 chip=0x0f318086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView Gen7' class = display subclass = VGA ahci0@pci0:0:19:0: class=0x010601 card=0x0f231849 chip=0x0f238086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView 6-Port SATA AHCI Controller' class = mass storage subclass = SATA xhci0@pci0:0:20:0: class=0x0c0330 card=0x0f351849 chip=0x0f358086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView USB xHCI Host Controller' class = serial bus subclass = USB none0@pci0:0:26:0: class=0x108000 card=0x0f181849 chip=0x0f188086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView SEC' class = encrypt/decrypt pcib1@pci0:0:28:0: class=0x060400 card=0x0f481849 chip=0x0f488086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'ValleyView PCI Express Root Port' class = bridge subclass = PCI-PCI pcib2@pci0:0:28:1: class=0x060400 card=0x0f4a1849 chip=0x0f4a8086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'ValleyView PCI Express Root Port' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:2: class=0x060400 card=0x0f4c1849 chip=0x0f4c8086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'ValleyView PCI Express Root Port' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:3: class=0x060400 card=0x0f4e1849 chip=0x0f4e8086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'ValleyView PCI Express Root Port' class = bridge subclass = PCI-PCI ehci0@pci0:0:29:0: class=0x0c0320 card=0x0f341849 chip=0x0f348086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView USB Enhanced Host Controller' class = serial bus subclass = USB isab0@pci0:0:31:0: class=0x060100 card=0x0f1c1849 chip=0x0f1c8086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView Power Control Unit' class = bridge subclass = PCI-ISA none1@pci0:0:31:3: class=0x0c0500 card=0x0f121849 chip=0x0f128086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView SMBus Controller' class = serial bus subclass = SMBus re0@pci0:2:0:0: class=0x02 card=0x81681849 chip=0x816810ec rev=0x11 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet --- dmesg.out --- Copyright (c) 1992-2014 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 10.1-RELEASE-p6 #0: Tue Feb 24 19:00:21 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver "vga". CPU: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz (2000.05-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x30673 Family = 0x6 Model = 0x37 Stepping = 3 Features=0xbfebfbff Features2=0x41d8e3bf AMD Features=0x28100800 AMD Features2=0x101 Structured Extended Features=0x2282 VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3790082048 (3614 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 cor
Re: Pass IGNORE_FILES to mergemaster in commandline
Am 01.10.2013 um 17:56 schrieb Łukasz Wąsikowski: > Hi all, > > How should I update config files in jails? I've always did it by running: > > IGNORE_FILES='/boot/device.hints /etc/motd' mergemaster -PFUi -D > /path/to/jail > > Now I'm getting *** FATAL ERROR: Unable to install ./boot/device.hints > to /path/to/jail/boot, so I assume that IGNORE_FILES is not used > anymore. I know, that the manual says that IGNORE_FILES can't be > overridden from commandline, but it worked. And it was good :) I'd > rather not want to go "edit /etc/mergemaster.rc" road, because I tend to > forget to change it back to defaults and it bitten me hard in the past. Hi. Putting e.g. IGNORE_FILES='/boot/device.hints /etc/motd /etc/hosts' in /etc/mergemaster.rc worked for me with 9.2-STABLE --Kai. -- GPG-Key: A593 E38B E968 4DBE 14D6 2115 7065 4D7C 4FB1 F588 Key available from hkps://hkps.pool.sks-keyservers.net PGP.sig Description: Signierter Teil der Nachricht
Re: gptzfsboot: error 4 lba 30
Am 02.04.2013 um 23:07 schrieb John Baldwin:
> On Monday, March 25, 2013 7:52:04 am Kai Gallasch wrote:
>> Hi.
>>
>> On one of my fresh installed servers I am seeing the following output during
> boot:
>>
>> gptzfsboot: error 4 lba 30
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 30
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>
> Humm, do you have disks that the BIOS sees that are small? An error code of 4
> means 'sector not found' or 'read error'. It would be interesting to see the
> output of 'lsdev -v' from the loader prompt.
Since upgrading the server to 9-STABLE (2013-03-30) the gptzfsboot error
message miraculously disappeared.
Because I upgraded the zpools on this particular server to a new version
("feature flags") I cannot boot back to 9.1-REL to find out if the upgrade was
the cause of this - or not.
When I bootup the server from a 9.1-REL USB stick, I also cannot reproduce the
error.
What did I change since seeing the error message the first time?
- I put GPT partitions on da2-da7 and used them for zpools
- Upgrading 9.1 REL to 9.1-2013-03-30
- refreshed the zfs bootcode on da0/da1 aferwards
If the error shows up again on a similar server soon to be upgraded, I'll give
feedback.
Kai.
___
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"
gptzfsboot: error 4 lba 30
Hi. On one of my fresh installed servers I am seeing the following output during boot: gptzfsboot: error 4 lba 30 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 30 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 (Not shortened, exactly those lines) The server then manages to boot from a mirrored zpool. What is the cause of error 4 lba 30/31 ? - controller is a hp/compaq p400 (ciss) - da0 - da7 are raid0 volumes (controller not jbod capable) - freebsd 9.1 REL (same error message with 9-STABLE from 2013-03-24) - server is zfs-only # diskinfo -v da0 da0 512 # sectorsize 146778685440# mediasize in bytes (136G) 286677120 # mediasize in sectors 0 # stripesize 0 # stripeoffset 35132 # Cylinders according to firmware. 255 # Heads according to firmware. 32 # Sectors according to firmware. P61620D9SUP9ZS # Disk ident. # gpart show => 34 286677053 da0 GPT (136G) 342561 freebsd-boot (128k) 290 2866767972 freebsd-zfs (136G) => 34 286677053 da1 GPT (136G) 342561 freebsd-boot (128k) 290 2866767972 freebsd-zfs (136G) Could this be drive geometry releated? (The hp/compaq raid0 drive is just presented to the O/S and is not identical to the raw device, because of raidcontroller on-disk meta information) If I remember correctly the the hp raid configuration tool also offers the possibility to create raid0 drives with 63 sector geometry. Regards, Kai. --- dmesg --- Copyright (c) 1992-2012 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 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Quad-Core AMD Opteron(tm) Processor 2389 (2900.17-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Family = 10 Model = 4 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant real memory = 30064771072 (28672 MB) avail memory = 28952248320 (27611 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x920-0x923 on acpi0 pcib0: on acpi0 pcib0: Length mismatch for 4 range: 918 vs 917 pci0: on pcib0 vgapci0: port 0x1000-0x10ff mem 0xe800-0xefff,0xf7ff-0xf7ff irq 44 at device 3.0 on pci0 pci0: at device 4.0 (no driver attached) pci0: at device 4.2 (no driver attached) uhci0: port 0x1800-0x181f irq 45 at device 4.4 on pci0 usbus0 on uhci0 pci0: at device 4.6 (no driver attached) pcib1: at device 5.0 on pci0 pci1: on pcib1 pcib2: at device 13.0 on pci1 pci2: on pcib2 177,0x376,0x500-0x50f at device 6.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 isab0: at device 6.2 on pci0 isa0: on isab0 ohci0: port 0x1c00-0x1cff mem 0xf7ee-0xf7ee0fff irq 5 at device 7.0 on pci0 usbus1 on ohci0 ohci1: port 0x3000-0x30ff mem 0xf7ed-0xf7ed0fff irq 5 at device 7.1 on pci0 usbus2 on ohci1 ehci0: port 0x3400-0x34ff mem 0xf7ec-0xf7ec0fff irq 5 at device 7.2 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib3: irq 42 at device 15.0 on pci0 pci5: on pcib3 pcib4: irq 38 at device 16.0 on pci0 pci8: on pcib4 pcib5: irq 39 at device 17.0 on pci0 pci14: on pcib5 pcib6: irq 40 at device 18.0 on pci0 pci11: on pcib6 pcib7: irq 41 at device 19.0 on pci0 pci3: on pcib7 pcib8: at device 0.0 on pci3 pci4: on pcib8 bce0: mem 0xf800-0xf9ff irq 41 at device 0.0 on pci4 bce0: /usr/src/s
Re: FreeBSD 9.1 - openldap slapd lockups, mutex problems
Am 22.01.2013 um 11:19 schrieb Kai Gallasch: > Hi. > > (Im am sending this to the "stable" list, because it maybe kernel related.. ) > > On 9.1-RELEASE I am witnessing lockups of the openldap slapd daemon. > > The slapd runs for some days and then hangs, consuming high amounts of CPU. > In this state slapd can only be restarted by SIGKILL. short update: I tried all I could to isolate the problem. What I am certain of is that the problem lies in the BDB backend for openldap itself, or how slapd interacts with it. My knowledge is not sufficient to debug BDB itself, it appears to be quite a complex gearbox. Also - as a sidenote - I had to learn that the new owner of BDB (orcle) does not give a toss about keeping old links to BDB documentation intact (for example informattion you'd need to tune your BDB - "DB_CONFIG" - or understand it better.) In the end I decided to drop the BDB backend for my running slapd installations and switch over to MDB[1,2] as backend and since then the problems disappeared. So if you are plagued by the same slapd lockups and rely on your ldap directory, switching backends will give you some peace of mind. Thanks to all who have replied! And thanks to sleepycat for all the fish. Kai Gallasch. [1] http://manpages.ubuntu.com/manpages/precise/man5/slapd-mdb.5.html [2] http://www.openldap.org/doc/admin24/backends.html ___ 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 9.1 - openldap slapd lockups, mutex problems
Hi. (Im am sending this to the "stable" list, because it maybe kernel related.. ) On 9.1-RELEASE I am witnessing lockups of the openldap slapd daemon. The slapd runs for some days and then hangs, consuming high amounts of CPU. In this state slapd can only be restarted by SIGKILL. # procstat -kk 71195 PIDTID COMM TDNAME KSTACK 71195 149271 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d do_wait+0x678 __umtx_op_wait+0x68 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 194998 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _cv_wait_sig+0x12e seltdwait+0x110 kern_select+0x6ef sys_select+0x5d amd64_syscall+0x546 Xfast_syscall+0xf7 71195 195544 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 196183 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_timedwait_sig+0x19 _sleep+0x2d4 userret+0x9e doreti_ast+0x1f 71195 197966 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 198446 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 198453 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 198563 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 199520 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 200038 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 200670 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 200674 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 200675 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 201179 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 201180 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 201181 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 201183 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 201189 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 When I try to stop slapd through the rc script I can see in the logs that the process is waiting for a thread to terminate - indefinitely. Other multithreaded server processes running on the server without problems (apache-worker, mysqld, bind, etc.) On UFS2 slapd runs fine, without showing the error. Things I have tried already to stop the lockups: - running openldap-server23, openldap24 both with different BDB backend versions. - tuning the BDB Init File - reducin
FreeBSD 9.0 - BCE_JUMBO_HDRSPLIT kernel option for bce device still needed?
Hi. I found the comment below in an older 8.1 kernel config file. # BCE_JUMBO_HDRSPLIT # freebsd-curr...@freebsd.org/2009-11/msg00065.html # [The bce driver does not have a memory leak, # it does however have a bug which causes memory # fragmentation leading to denied mbuf allocation.] #=20 # You need to put "options BCE_JUMBO_HDRSPLIT" # In your kernel to enable the work arround. Is the kernel option BCE_JUMBO_HDRSPLIT still needed for a FreeBSD 9 kernel if you use the bce device (broadcom) ? I find it in the 9.0 kernel LINT file but it's not part of the GENERIC kernel. Kai.___ 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: FreeBSD 9.0 release - memstick installation fails
> Hi list. > > Trying to install 9.0 release with a USB stick. > I use FreeBSD-9.0-RELEASE-amd64-memstick.img > > At first the bootup looks promising, but in the end it stops with "Root mount > waiting for: usbus2 usbus1 usbus" Just for the records: Someone already had opened up a PR for this. http://www.freebsd.org/cgi/query-pr.cgi?pr=164773 Kai. ___ 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: FreeBSD 9.0 release - memstick installation fails
On Fri, 2012-03-02 Sean Bruno wrote: > You may want to try playing around with BIOS settings regarding USB. I'd happily do so, but unfortunately this BIOS.. PhoenixBIOS 4.0 Release 6.1 HP System BIOS - O09 (07/19/2007) HP FEATURES VERSION : 1.08.00 has no USB knobs to turn. Kai. > On Fri, 2012-03-02 at 13:01 -0800, Kai Gallasch wrote: >> Hi list. >> >> Trying to install 9.0 release with a USB stick. >> I use FreeBSD-9.0-RELEASE-amd64-memstick.img >> >> At first the bootup looks promising, but in the end it stops with "Root >> mount waiting for: usbus2 usbus1 usbus" >> >> To single out a bad USB stick I tried FreeBSD-8.3-BETA1-amd64-memstick.img >> with the same stick and there are no problems. >> >> The hardware is an older HP/Compaq DL145-G3, but why toss it in the trash? >> >> How can I debug this further? >> Any hints? >> >> Kai. >> >> >> snip >> >> SMAP type=01 base= len=0009c000 >> SMAP type=02 base=0009c000 len=4000 >> SMAP type=02 base=000ce000 len=00032000 >> SMAP type=01 base=0010 len=dbe6 >> SMAP type=03 base=dbf6 len=7000 >> SMAP type=04 base=dbf67000 len=00019000 >> SMAP type=02 base=dbf8 len=0008 >> SMAP type=02 base=e000 len=1000 >> SMAP type=02 base=fec0 len=3000 >> SMAP type=02 base=fee0 len=1000 >> SMAP type=02 base=fff8 len=0008 >> SMAP type=01 base=0001 len=00012400 >> Table 'FACP' at 0xdbf62be7 >> Table 'SPMI' at 0xdbf66bf5 >> Table 'SSDT' at 0xdbf66c35 >> Table 'HPET' at 0xdbf66e7d >> Table 'SSDT' at 0xdbf66eb5 >> Table 'MCFG' at 0xdbf66efe >> Table 'SPCR' at 0xdbf66f3a >> Table 'APIC' at 0xdbf66f8a >> APIC: Found table at 0xdbf66f8a >> APIC: Using the MADT enumerator. >> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled >> SMP: Added CPU 0 (AP) >> MADT: Found CPU APIC ID 1 ACPI ID 1: enabled >> SMP: Added CPU 1 (AP) >> Copyright (c) 1992-2012 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 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 >> r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >> Table 'FACP' at 0xdbf62be7 >> Table 'SPMI' at 0xdbf66bf5 >> Table 'SSDT' at 0xdbf66c35 >> Table 'HPET' at 0xdbf66e7d >> Table 'SSDT' at 0xdbf66eb5 >> Table 'MCFG' at 0xdbf66efe >> Table 'SPCR' at 0xdbf66f3a >> Table 'APIC' at 0xdbf66f8a >> ACPI: No SRAT table found >> Preloaded elf kernel "/boot/kernel/kernel" at 0x813cf000. >> Calibrating TSC clock ... TSC clock: 2394059007 Hz >> CPU: Dual-Core AMD Opteron(tm) Processor 2216 HE (2394.06-MHz K8-class CPU) >> Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 >> Features=0x178bfbff >> Features2=0x2001 >> AMD Features=0xea500800 >> AMD Features2=0x1f >> L1 2MB data TLB: 8 entries, fully associative >> L1 2MB instruction TLB: 8 entries, fully associative >> L1 4KB data TLB: 32 entries, fully associative >> L1 4KB instruction TLB: 32 entries, fully associative >> L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative >> L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way >> associative >> L2 2MB unified TLB: 0 entries, disabled/not present >> L2 4KB data TLB: 512 entries, 4-way associative >> L2 4KB instruction TLB: 512 entries, 4-way associative >> L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative >> real memory = 8589934592 (8192 MB) >> Physical memory chunk(s): >> 0x1000 - 0x00097fff, 618496 bytes (151 pages) >> 0x0010 - 0x001f, 1048576 bytes (256 pages) >> 0x01403000 - 0xdbf5, 3669348352 bytes (895837 pages) >> 0x0001 - 0x000213e45fff, 4628701184 bytes (1130054 pages) >> avail memory = 8244486144 (7862 MB) >> Event timer "LAPIC" quality 400 >> ACPI APIC Table: >> INTR: Adding local APIC 1 as a target >> FreeBSD/SMP: Multiproc
FreeBSD 9.0 release - memstick installation fails
Hi list. Trying to install 9.0 release with a USB stick. I use FreeBSD-9.0-RELEASE-amd64-memstick.img At first the bootup looks promising, but in the end it stops with "Root mount waiting for: usbus2 usbus1 usbus" To single out a bad USB stick I tried FreeBSD-8.3-BETA1-amd64-memstick.img with the same stick and there are no problems. The hardware is an older HP/Compaq DL145-G3, but why toss it in the trash? How can I debug this further? Any hints? Kai. snip SMAP type=01 base= len=0009c000 SMAP type=02 base=0009c000 len=4000 SMAP type=02 base=000ce000 len=00032000 SMAP type=01 base=0010 len=dbe6 SMAP type=03 base=dbf6 len=7000 SMAP type=04 base=dbf67000 len=00019000 SMAP type=02 base=dbf8 len=0008 SMAP type=02 base=e000 len=1000 SMAP type=02 base=fec0 len=3000 SMAP type=02 base=fee0 len=1000 SMAP type=02 base=fff8 len=0008 SMAP type=01 base=0001 len=00012400 Table 'FACP' at 0xdbf62be7 Table 'SPMI' at 0xdbf66bf5 Table 'SSDT' at 0xdbf66c35 Table 'HPET' at 0xdbf66e7d Table 'SSDT' at 0xdbf66eb5 Table 'MCFG' at 0xdbf66efe Table 'SPCR' at 0xdbf66f3a Table 'APIC' at 0xdbf66f8a APIC: Found table at 0xdbf66f8a APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) Copyright (c) 1992-2012 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 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Table 'FACP' at 0xdbf62be7 Table 'SPMI' at 0xdbf66bf5 Table 'SSDT' at 0xdbf66c35 Table 'HPET' at 0xdbf66e7d Table 'SSDT' at 0xdbf66eb5 Table 'MCFG' at 0xdbf66efe Table 'SPCR' at 0xdbf66f3a Table 'APIC' at 0xdbf66f8a ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel/kernel" at 0x813cf000. Calibrating TSC clock ... TSC clock: 2394059007 Hz CPU: Dual-Core AMD Opteron(tm) Processor 2216 HE (2394.06-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x1000 - 0x00097fff, 618496 bytes (151 pages) 0x0010 - 0x001f, 1048576 bytes (256 pages) 0x01403000 - 0xdbf5, 3669348352 bytes (895837 pages) 0x0001 - 0x000213e45fff, 4628701184 bytes (1130054 pages) avail memory = 8244486144 (7862 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 x86bios: IVT 0x00-0x0004ff at 0xfe00 x86bios: SSEG 0x001000-0x001fff at 0xff800022 x86bios: EBDA 0x09c000-0x09 at 0xfe09c000 x86bios: ROM 0x0a-0x0fefff at 0xfe0a APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xf8510 00024 (v02 PTLTD ) ACPI: XSDT 0xdbf62b83 00064 (v01 PTLTD ? XSDT 0604 LTP ) ACPI: FACP 0xdbf62be7 00084 (v02 HP TREX 0604 MSFT 0201) ACPI: DSDT 0xdbf62c6b 03F8A (v01 HP TREX 0604 MSFT 0202) ACPI: FACS 0xdbf6ffc0 00040 ACPI: SPMI 0xdbf66bf5 00040 (v05 HP TREX 0604 PTL 0001) ACPI: SSDT 0xdbf66c35 00248 (v01 PTLTD POWERNOW 0604 LTP 0001) ACPI: HPET 0xdbf66e7d 00038 (v01 BRCM EXPLOSN 0604 BRCM 0201) ACPI: SSDT 0xdbf66eb5 00049 (v01 PTLTDSSDT 0604 AMD 0201) ACPI: MCFG 0xdbf66efe 0003C (v01 PTLTDMCFG 0604 AMD 0201) ACPI: SPCR 0xdbf66f3a 00050 (v01 PTLTD $UCRTBL$ 0604 PTL 0001) ACPI: APIC 0xdbf66f8a 00076 (v01 PTLTDAPIC 0604 LTP ) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec0 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 3, Interrupt 16 at 0xfec01000 MADT: Found IO APIC
Re: proliant server lockups with freebsd-amd64-stable (2010-03-10)
> Am Fri, 12 Mar 2010 20:38:31 +0200 > schrieb Alexander Motin : > > > Pawel Jakub Dawidek wrote: > > > On Thu, Mar 11, 2010 at 01:39:16PM +0100, Kai Gallasch wrote: > > >> I have some trouble with an opteron server locking up > > >> spontaneously. It looses all networks connectivity and even > > >> through console I can get no shell. > > >> > > >> Lockups occur mostly under disk load (periodic daily, bacula > > >> backup running, make buildworld/buildkernel) and I can provoke > > >> them easily. > > > [...] > > >> 4 0 0 0 LL *cissmtx 0xff04ed820c00 > > >> [g_down] > > > [...] > > >> 100046 L *cissmtx 0xff04ed820c00 > > >> [irq257: ciss0] > > > [...] > > > > > > I was analizing similar problem as potential ZFS bug. It turned > > > out to be bug in ciss(4) and I believe mav@ (CCed) has fix for > > > that. > > > > That my patch is already at 8-STABLE since r204873 of 2010-03-08. > > Make sure you have it. Rebuilding the kernel with your 8-STABLE commited ciss patch seems to have resolved this issue. Server now has an uptime of 5 days and survives under high filesystem load. Alexander, thanks for fixing ciss. Kai. -- Da das Pferd pfluegt, lasst uns den Esel satteln. ___ 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: proliant server lockups with freebsd-amd64-stable (2010-03-10)
Am Fri, 12 Mar 2010 20:38:31 +0200
schrieb Alexander Motin :
> Pawel Jakub Dawidek wrote:
> > On Thu, Mar 11, 2010 at 01:39:16PM +0100, Kai Gallasch wrote:
> >> I have some trouble with an opteron server locking up
> >> spontaneously. It looses all networks connectivity and even
> >> through console I can get no shell.
> >>
> >> Lockups occur mostly under disk load (periodic daily, bacula backup
> >> running, make buildworld/buildkernel) and I can provoke them
> >> easily.
> > [...]
> >> 4 0 0 0 LL *cissmtx 0xff04ed820c00
> >> [g_down]
> > [...]
> >> 100046 L *cissmtx 0xff04ed820c00
> >> [irq257: ciss0]
> > [...]
> >
> > I was analizing similar problem as potential ZFS bug. It turned out
> > to be bug in ciss(4) and I believe mav@ (CCed) has fix for that.
>
> That my patch is already at 8-STABLE since r204873 of 2010-03-08. Make
> sure you have it.
Updating collection src-all/cvs
..
..
Edit src/sys/dev/ciss/ciss.c
Edit src/sys/dev/ciss/cissvar.h
Didn't have it! Must have been just a few hours I missed it,
when I built the last kernel. So I will rebuild my kernel and
give it a spin later on.
> In this case trap stopped process at ciss_get_request(), which indeed
> called holding cissmtx lock. But there is no place to sleep or loop
> there, so may be it was just spontaneous. With bugs I was fixing there
> was a chance to loop indefinitely between ciss and CAM on resource
> constraint. That increases chance for such situation to be caught.
>
> You may try also look what's going on with `top -HS` and `systat -vm
> 1`.
FYI. Without your patch of ciss.c and cissvar.h a lockup with top -HS
and systat -vm running gives following information below. Is there a
pattern visible relating to your patch of the ciss driver?
Kai.
-- vmstat -vm --
3 usersLoad 0.21 0.36 0.45 Mar 12 21:47
Mem:KBREALVIRTUAL VN PAGER SWAP PAGER
Tot Share TotShareFree in out in out
Act 2805456 40804 6269932079936 12358k count
All 6182560 95796 1136820k 212452 pages
Proc:Interrupts
r p d s w Csw Trp Sys Int Sof Fltcow 16018 total
491 533 28 576 19 179 174zfodatkbd0 1
ozfod uart0 irq4
12.9%Sys 12.5%Intr 0.1%User 0.0%Nice 74.5%Idle%ozfod ata0 irq14
||||||||||| daefr uhci0 45
==+++ prcfr 2000 cpu0: time
87 dtbuf totfr19 bce0 256
Namei Name-cache Dir-cache10 desvn react ciss0 257
Callshits %hits % 40811 numvn pdwak 2000 cpu1: time
17300 frevn pdpgs 2000 cpu4: time
intrn 2000 cpu5: time
Disks da0 da1 da2 da3 da4 pass0 pass1 4995516 wire 2000 cpu6: time
KB/t 0.00 0.00 0.00 0.00 0.00 0.00 0.00 2593276 act1999 cpu7: time
tps 0 0 0 0 0 0 0369560 inact 2000 cpu3: time
MB/s 0.00 0.00 0.00 0.00 0.00 0.00 0.00 9568 cache 2000 cpu2: time
%busy 0 0 0 0 0 0 0 12348752 free
1252272 buf
--- top -HS
last pid: 42561; load averages: 0.35, 0.38, 0.46up
0+11:24:36 21:53:39
658 processes: 13 running, 623 sleeping, 21 waiting, 1 lock
CPU: 0.6% user, 0.0% nice, 12.6% system, 25.0% interrupt, 61.8% idle
Mem: 2559M Active, 363M Inact, 4892M Wired, 9548K Cache, 1223M Buf, 12G Free
Swap: 21G Total, 21G Free
PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
11 root 171 ki31 0K 128K CPU33 672:22 100.00% {idle: cpu3}
11 root 171 ki31 0K 128K CPU11 663:50 100.00% {idle: cpu1}
11 root 171 ki31 0K 128K RUN 4 649:18 100.00% {idle: cpu4}
12 root -32- 0K 384K CPU70 6:38 100.00% {swi4:
clock}
4 root -8- 0K16K CPU55 1:16 100.00% g_down
12 root -64- 0K 384K CPU20 1:15 100.00% {swi2:
cambio}
11 root 171 ki31 0K 128K CPU66 672:13 97.27% {idle: cpu6}
11 root 171 ki31 0K 128K CPU00 622:18 96.29% {idle: cpu0}
11 root 171 ki31 0K 128K RUN 7 676:57 10.99% {idle: cpu7}
2046 zope1 460 468M 379M ucond 6 7:30 1.76% {pyth
