Re: kern.geom.part.check_integrity=0 not working. not able to boot 9-STABLE
On 20.06.2012 22:23, Ruben de Groot wrote: > ata2: reset tp2 stat0=50 stat1=00 devices=0x1 > (ada0:ata2:0:0:0): Command timed out > (ada0:ata2:0:0:0): Retrying command > ata2: reset tp1 mask=03 ostat0=58 ostat1=00 > ata2: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 > ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 > ata2: reset tp2 stat0=50 stat1=00 devices=0x1 > (ada0:ata2:0:0:0): Command timed out > (ada0:ata2:0:0:0): Retrying command It seems it is not related to the problem with integrity checks. -- WBR, Andrey V. Elsukov ___ 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: Seeking 6.4 make source for ports
Michael R. Wayne wrote: Upgrading a port can be done without rebooting the machine. Upgrading the O/S is a MUCH more major undertaking and is almost never a "clean" process. Plus the time investment multiplied by many machines is huge (and dreaded). 6.x->7 was pretty painless. The machine was down for about 20mins while I did the installkernel/installworld step. I was in a bit of a rush so I didn't do the full mergemaster on /etc at that point in time and the only quirk I saw was a PAM auth warning in the log that didn't impact anything in the configuration I was using. This was fixed when I did the mergemaster on /etc (which I did on a snapshot later). At this point in time the machine was still running ports compiled in the 5.x timeframe. I then created a chroot environment to do the ports update in. Mike -- Mike Pumford, Senior Software Engineer MPC Data Limited e-mail: mpumf...@mpcdata.comweb: www.mpcdata.com tel: +44 (0) 1225 710600fax: +44 (0) 1225 710601 ddi: +44 (0) 1225 710635 ___ 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"
Network unavailable when booting directly to FreeBSD.
Hello; I noticed a regression from 9.0 and I cannot boot directly FreeBSD and access the network. Unfortunately I cannot recall the exact commit where this started happening. uname -a FreeBSD pcbsd-8555 9.0-STABLE FreeBSD 9.0-STABLE #12: Wed May 30 11:16:35 PDT 2012 r...@build9x64.pcbsd.org:/usr/obj/builds/amd64/pcbsd-build90/fbsd-source/9.0/sys/GENERIC amd64 From my dmesg __ ... pcib0: port 0xcf8-0xcff on acpi0 pcib0: Length mismatch for 4 range: 81 vs 7f pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 bge0: 0x00b002> mem 0xfdef-0xfdef irq 16 at device 0.0 on pci2 bge0: CHIP ID 0xb002; ASIC REV 0x0b; CHIP REV 0xb0; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:18:8b:76:a4:1e pcib3: at device 4.0 on pci0 pci3: on pcib3 Cuse4BSD v0.1.23 @ /dev/cuse bge0: watchdog timeout -- resetting bge0: watchdog timeout -- resetting WARNING: attempt to domain_add(bluetooth) after domainfinalize() fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP _ Iff I boot Windows first and then reboot to start FreeBSD the network works fine. Pedro. ___ 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"
[CFT] Need Testers for: sysutils/bsdconfig
Hi everybody, I've published a new port (sysutils/bsdconfig) so that we can get some testing on the replacement for sysinstall's [post-installation] "Configure" menu. We're on a tight schedule, so if you have the time and/or energy your timely efforts will be GREATLY appreciated in helping to get this software tested prior to the 9.1-R code freeze. Please welcome "bsdconfig" (port pkg-descr below): bsdconfig is a robust utility for configuring/managing various aspects of the FreeBSD Operating System. Feature-highlights include (but are not limited to): - Modular, stable, efficient and i18n-compatible. - Easily maintained/extendable sh(1) source/syntax. - Works with both dialog(1) in base and Xdialog(1) from ports (x11/xdialog). - rc.conf(5) configuration/management based on sysutils/sysrc - Timezone configuration based on sysutils/tzdialog - Networking management based on sysutils/host-setup WWW: http://druidbsd.sourceforge.net/ Again, thank you very much for testing this new software. -- Devin P.S. Due to the large codebase comprising bsdconfig, ample precautions should be taken. I've not noticed any negative behavior in months of usage, but just be warned. P.P.S. I don't think on subscribed to -stable@, so include me in your replies. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: [CFT] Need Testers for: sysutils/bsdconfig
Sorry, forgot to mention… The port will only install/work on 9.0 or higher. Testing needed on FreeBSD 9.0-R (or higher) and/or PC-BSD 9.0-R (or higher). -- Devin On Jun 21, 2012, at 3:32 PM, Devin Teske wrote: > Hi everybody, > > I've published a new port (sysutils/bsdconfig) so that we can get some > testing on the replacement for sysinstall's [post-installation] "Configure" > menu. > > We're on a tight schedule, so if you have the time and/or energy your timely > efforts will be GREATLY appreciated in helping to get this software tested > prior to the 9.1-R code freeze. > > Please welcome "bsdconfig" (port pkg-descr below): > > bsdconfig is a robust utility for configuring/managing various aspects of the > FreeBSD Operating System. Feature-highlights include (but are not limited to): > - Modular, stable, efficient and i18n-compatible. > - Easily maintained/extendable sh(1) source/syntax. > - Works with both dialog(1) in base and Xdialog(1) from ports (x11/xdialog). > - rc.conf(5) configuration/management based on sysutils/sysrc > - Timezone configuration based on sysutils/tzdialog > - Networking management based on sysutils/host-setup > > WWW: http://druidbsd.sourceforge.net/ > > Again, thank you very much for testing this new software. > -- > Devin > > P.S. Due to the large codebase comprising bsdconfig, ample precautions should > be taken. I've not noticed any negative behavior in months of usage, but just > be warned. > > P.P.S. I don't think on subscribed to -stable@, so include me in your replies. > > _ > The information contained in this message is proprietary and/or confidential. > If you are not the intended recipient, please: (i) delete the message and all > copies; (ii) do not disclose, distribute or use the message in any manner; > and (iii) notify the sender immediately. In addition, please be aware that > any message addressed to our domain is subject to archiving and review by > persons other than the intended recipient. Thank you. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: Network unavailable when booting directly to FreeBSD.
On Thu, 2012-06-21 at 12:05 -0700, Pedro Giffuni wrote: > Hello; > > I noticed a regression from 9.0 and I cannot boot directly FreeBSD > and access the network. Unfortunately I cannot recall the exact > commit where this started happening. > > uname -a > FreeBSD pcbsd-8555 9.0-STABLE FreeBSD 9.0-STABLE #12: Wed May 30 > 11:16:35 PDT 2012 > r...@build9x64.pcbsd.org:/usr/obj/builds/amd64/pcbsd-build90/fbsd-source/9.0/sys/GENERIC > > amd64 > > From my dmesg > __ > ... > pcib0: port 0xcf8-0xcff on acpi0 > pcib0: Length mismatch for 4 range: 81 vs 7f > pci0: on pcib0 > pci0: at device 0.0 (no driver attached) > pci0: at device 0.1 (no driver attached) > pci0: at device 0.2 (no driver attached) > pci0: at device 0.3 (no driver attached) > pci0: at device 0.4 (no driver attached) > pci0: at device 0.5 (no driver attached) > pci0: at device 0.6 (no driver attached) > pci0: at device 0.7 (no driver attached) > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pcib2: at device 3.0 on pci0 > pci2: on pcib2 > bge0: 0x00b002> mem 0xfdef-0xfdef irq 16 at device 0.0 on pci2 > bge0: CHIP ID 0xb002; ASIC REV 0x0b; CHIP REV 0xb0; PCI-E > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: Ethernet address: 00:18:8b:76:a4:1e > pcib3: at device 4.0 on pci0 > pci3: on pcib3 > > > Cuse4BSD v0.1.23 @ /dev/cuse > bge0: watchdog timeout -- resetting > bge0: watchdog timeout -- resetting > WARNING: attempt to domain_add(bluetooth) after domainfinalize() > fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 > bge0: watchdog timeout -- resetting > bge0: link state changed to DOWN > bge0: link state changed to UP > bge0: watchdog timeout -- resetting > bge0: link state changed to DOWN > bge0: link state changed to UP > bge0: watchdog timeout -- resetting > bge0: link state changed to DOWN > bge0: link state changed to UP > _ > > Iff I boot Windows first and then reboot to start FreeBSD the network > works fine. > > Pedro. I wonder if this is the one that caused your problems? http://svnweb.freebsd.org/base?view=revision&revision=233495 Can you post the full verbose dmesg and the output of pciconf -lvb for review? Sean ___ 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: Network unavailable when booting directly to FreeBSD.
--- Gio 21/6/12, Sean Bruno ha scritto: > On Thu, 2012-06-21 at 12:05 -0700, Pedro Giffuni wrote: > > Hello; > > > > I noticed a regression from 9.0 and I cannot boot > directly FreeBSD > > and access the network. Unfortunately I cannot recall > the exact > > commit where this started happening. > > > > uname -a > > FreeBSD pcbsd-8555 9.0-STABLE FreeBSD 9.0-STABLE #12: > Wed May 30 > > 11:16:35 PDT 2012 > > r...@build9x64.pcbsd.org:/usr/obj/builds/amd64/pcbsd-build90/fbsd-source/9.0/sys/GENERIC > > > amd64 > > ... > > I wonder if this is the one that caused your problems? > > http://svnweb.freebsd.org/base?view=revision&revision=233495 > I will have a look at reverting it locally. > Can you post the full verbose dmesg http://people.freebsd.org/~pfg/dmesg-bge-error.txt > and the output of pciconf -lvb http://people.freebsd.org/~pfg/pciconf.txt > for review? > Thanks! Pedro. ___ 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: mfi(4) IO performance regression, post 8.1
On 6/15/12 8:04 AM, John Baldwin wrote:
On Friday, June 15, 2012 12:28:59 am Charles Owens wrote:
Hello FreeBSD folk,
We're seeing what appears to be a storage performance regression as we
try to move from 8.1 (i386) to 8.3. We looked at 8.2 also and it
appears that the regression happened between 8.1 and 8.2.
Our system is an Intel S5520UR Server with 12 GB RAM, dual 4-core CPUs.
Storage is a LSI MegaSAS 1078 controller (mfi) in a RAID-10
configuration, using UFS + geom_journal for filesystem.
Postgresql performance, as seen via pgbench, dropped by approx 20%.
This testing was done with our usual PAE-enabled kernels. We then went
back to GENERIC kernels and did comparisons using "bonnie", results
below. Following that is a kernel boot log.
Notably, we're seeing this regression only with our RAID mfi(4) based
systems. Notably, from looking at FreeBSD source changelogs it appears
that the mfi(4) code has seen some changes since 8.1.
Between 8.1 and 8.2 mfi has not had any significant changes. The only changes
made to sys/dev/mfi were to add a new constant:
svn diff svn+ssh://svn.freebsd.org/base/releng/8.1/sys/dev/mfi
svn+ssh://svn.freebsd.org/base/releng/8.2/sys/dev/mfi
Index: mfireg.h
===
--- mfireg.h(.../8.1/sys/dev/mfi) (revision 237134)
+++ mfireg.h(.../8.2/sys/dev/mfi) (revision 237134)
@@ -975,7 +975,9 @@
MFI_PD_STATE_OFFLINE = 0x10,
MFI_PD_STATE_FAILED = 0x11,
MFI_PD_STATE_REBUILD = 0x14,
- MFI_PD_STATE_ONLINE = 0x18
+ MFI_PD_STATE_ONLINE = 0x18,
+ MFI_PD_STATE_COPYBACK = 0x20,
+ MFI_PD_STATE_SYSTEM = 0x40
};
union mfi_ld_ref {
The difference in write performance must be due to something else. You
mentioned you are using UFS + gjournal. I think gjournal uses BIO_FLUSH, so I
wonder if this is related:
r212939 | gibbs | 2010-09-20 19:39:00 -0400 (Mon, 20 Sep 2010) | 61 lines
MFC 212160:
Correct bioq_disksort so that bioq_insert_tail() offers barrier semantic.
Add the BIO_ORDERED flag for struct bio and update bio clients to use it.
The barrier semantics of bioq_insert_tail() were broken in two ways:
o In bioq_disksort(), an added bio could be inserted at the head of
the queue, even when a barrier was present, if the sort key for
the new entry was less than that of the last queued barrier bio.
o The last_offset used to generate the sort key for newly queued bios
did not stay at the position of the barrier until either the
barrier was de-queued, or a new barrier (which updates last_offset)
was queued. When a barrier is in effect, we know that the disk
will pass through the barrier position just before the
"blocked bios" are released, so using the barrier's offset for
last_offset is the optimal choice.
sys/geom/sched/subr_disk.c:
sys/kern/subr_disk.c:
o Update last_offset in bioq_insert_tail().
o Only update last_offset in bioq_remove() if the removed bio is
at the head of the queue (typically due to a call via
bioq_takefirst()) and no barrier is active.
o In bioq_disksort(), if we have a barrier (insert_point is non-NULL),
set prev to the barrier and cur to it's next element. Now that
last_offset is kept at the barrier position, this change isn't
strictly necessary, but since we have to take a decision branch
anyway, it does avoid one, no-op, loop iteration in the while
loop that immediately follows.
o In bioq_disksort(), bypass the normal sort for bios with the
BIO_ORDERED attribute and instead insert them into the queue
with bioq_insert_tail(). bioq_insert_tail() not only gives
the desired command order during insertion, but also provides
barrier semantics so that commands disksorted in the future
cannot pass the just enqueued transaction.
sys/sys/bio.h:
Add BIO_ORDERED as bit 4 of the bio_flags field in struct bio.
sys/cam/ata/ata_da.c:
sys/cam/scsi/scsi_da.c
Use an ordered command for SCSI/ATA-NCQ commands issued in
response to bios with the BIO_ORDERED flag set.
sys/cam/scsi/scsi_da.c
Use an ordered tag when issuing a synchronize cache command.
Wrap some lines to 80 columns.
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
sys/geom/geom_io.c
Mark bios with the BIO_FLUSH command as BIO_ORDERED.
Sponsored by: Spectra Logic Corporation
Can you try perhaps commenting out the 'bp->bio_flags |= BIO_ORDERED' line
changed in geom_io.c in 8.2? That would be effectively reverting this
portion of the diff:
Index: geom_io.c
===
--- geom_io.c (.../8.1/sys/geom)
Re: [CFT] Need Testers for: sysutils/bsdconfig
On 6/21/12 5:32 PM, Devin Teske wrote: Hi everybody, I've published a new port (sysutils/bsdconfig) so that we can get some testing on the replacement for sysinstall's [post-installation] "Configure" menu. We're on a tight schedule, so if you have the time and/or energy your timely efforts will be GREATLY appreciated in helping to get this software tested prior to the 9.1-R code freeze. Please welcome "bsdconfig" (port pkg-descr below): bsdconfig is a robust utility for configuring/managing various aspects of the FreeBSD Operating System. Feature-highlights include (but are not limited to): - Modular, stable, efficient and i18n-compatible. - Easily maintained/extendable sh(1) source/syntax. - Works with both dialog(1) in base and Xdialog(1) from ports (x11/xdialog). - rc.conf(5) configuration/management based on sysutils/sysrc - Timezone configuration based on sysutils/tzdialog - Networking management based on sysutils/host-setup WWW: http://druidbsd.sourceforge.net/ Again, thank you very much for testing this new software. P.S. Due to the large codebase comprising bsdconfig, ample precautions should be taken. I've not noticed any negative behavior in months of usage, but just be warned. P.P.S. I don't think on subscribed to -stable@, so include me in your replies. I'm one of the coauthors of this code, and I am here on -stable. As stated, this port will only run on 9.0-RELEASE and later. Please give it a try! Thanks! -- Ron McDowell San Antonio TX ___ 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"
