Re: HEADS UP: Major CAM performance regression
2009/2/13 Scott Long : > Ivan Voras wrote: >> >> Scott Long wrote: >> >>> I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN >>> revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few >>> days once I've gotten confirmation that the fix works and doesn't cause >>> any adverse side-effects. Anyone wanting to help in this validation >>> effort should apply the attached patch to their kernel source tree and >>> recompile. Please contact me directly by email to report if the problem >>> is fixed for you. >> >> I notice that write performance on an ESXi 3.5 hosted system is doubled, >> but read performance remains the same (in bonnie++). >> On a CISS system there is no significant change. > > bonnie is an unreliable tool for measuring performance. I'll try your suggestion if you have one. (except if it's about bonnie++ primarily measuring sequential read/write - if a system can't do sequential IO well, it probably won't do random IO well) ___ 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 CVS problem ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Lamaizière wrote: > Hi, > > I've just found that the files for glxsb(4) in RELENG_7 are older than > in RELENG_7_1. I don't think this is normal? > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/glxsb/glxsb.c?only_with_tag=RELENG_7 > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/glxsb/glxsb.c?only_with_tag=RELENG_7_1 > > RELENG_7_1 contains changes made by philip@ in SVN rev 185021 > > RELENG_7 contains an older version SVN rev 181919 on 2008-08-20 > 11:33:13Z by philip > > If you know how solve this, thanks. > Regards. "older" is just meaningful on the same branch... This is normal. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmV8iAACgkQi+vbBBjt66CDeACgrUSl37l5lBLqbJUFXvCD08nl aNkAoKcuzVLNcZWxwfVXuAjktN2gIee/ =wCfl -END PGP SIGNATURE- ___ 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: HEADS UP: Major CAM performance regression
Ivan Voras wrote: Scott Long wrote: I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few days once I've gotten confirmation that the fix works and doesn't cause any adverse side-effects. Anyone wanting to help in this validation effort should apply the attached patch to their kernel source tree and recompile. Please contact me directly by email to report if the problem is fixed for you. I notice that write performance on an ESXi 3.5 hosted system is doubled, but read performance remains the same (in bonnie++). On a CISS system there is no significant change. bonnie is an unreliable tool for measuring performance. Scott ___ 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: HEADS UP: Major CAM performance regression
Tom Evans wrote: On Fri, 2009-02-13 at 03:55 -0700, Scott Long wrote: All, A major performance regression was introduced to the CAM subsystem in FreeBSD 7.1. The following configurations are known to be affected: VMWare ESX VMWare Fusion (using bt or lsilogic controller options) HP CISS RAID Some MPT-SAS combinations with SATA drives attached (Includes Dell SAS5/ir, but not PERC5/PERC6). Pure SCSI and SAS subsystems likely are NOT affected. Any hardware that uses the 'ata' driver is also definitely NOT affected. To determine if your installation is affected, run the following command as root: camcontrol tags da0 Substitute 'da0' with another appropriate drive device number, if needed. Note that this ONLY AFFECTS 'da' DEVICES. If your disks are 'ad' devices, they are NOT affected. The result from running this command should be an output similar to the following: (pass0:mpt0:0:8:0): device openings: 255 If, instead, it reports a value of '1', you are likely affected. Note that it may be normal for USB memory devices to report a low number. Also, many legacy SCSI disks, and devices that are not disks, may also be expected to report a low number. The effect of this problem is that only one I/O command will be issued to the controller and disk at a time, instead of overlapping multiple commands in parallel. This causes significantly higher latency in servicing moderate and heavy I/O workloads, leading to very poor performance. Performance can be easily compared by downgrading to FreeBSD 7.0. I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few days once I've gotten confirmation that the fix works and doesn't cause any adverse side-effects. Anyone wanting to help in this validation effort should apply the attached patch to their kernel source tree and recompile. Please contact me directly by email to report if the problem is fixed for you. If the validation process goes smoothly, I will work with the release engineering team to turn this fix into an official errata update for FreeBSD 7.1. Thanks in advance for your help. Scott Hi Scott I have one da0 device, a USB attached hard disk: umass0: on uhub6 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) camcontrol shows: $ sudo camcontrol tags da0 (pass0:umass-sim0:0:0:0): device openings: 1 Is that to be expected? This is RELENG_7 from October '08: The date falls within the range. Have you tried the patch to see if it changes anything? Scott ___ 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 CVS problem ?
Hi, I've just found that the files for glxsb(4) in RELENG_7 are older than in RELENG_7_1. I don't think this is normal? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/glxsb/glxsb.c?only_with_tag=RELENG_7 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/glxsb/glxsb.c?only_with_tag=RELENG_7_1 RELENG_7_1 contains changes made by philip@ in SVN rev 185021 RELENG_7 contains an older version SVN rev 181919 on 2008-08-20 11:33:13Z by philip If you know how solve this, thanks. Regards. ___ 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: Backport of glxsb(4) to RELENG_6
Le Fri, 13 Feb 2009 15:43:33 +0100, Patrick Lamaizière : > Le Thu, 12 Feb 2009 22:34:43 +0100, > Lars Engels : > > Hi, > > > I just tried it, but I get this message: > > glxsb0: mem > > 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 > > > glxsb0: cannot allocate DMA memory of 32768 bytes (12) > > I think you are very low on memory and the driver cannot allocate his > DMA-able buffer (error 12=ENOMEM) > > This is not really a bug. To Lars: Yes it should work at bootime. You must also load the module cryptodev.ko to use it with openssl. > But i've found another problem related to > the taskqueue. > > I'm doing a fake driver to be able to test on a vmware machine. I've tested most of the driver and I think (hope) this is ok. http://user.lamaiziere.net/patrick/glxsb-6-130209.tar.gz Let me know how it works. Regards. ___ 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: pkg_delete segfaulting after upgrading to 7.1
On Thu, Feb 12, 2009 at 10:29 PM, Henry Hu wrote: >> rosbox# pkg_delete -f gpgme-1.1.5_1 >> pkg_delete: package 'gpgme-1.1.5_1' is required by these other packages >> and may not be deinstalled (but I'll delete it anyway): >> seahorse-2.24.1_1 >> Segmentation fault (core dumped) > > I've had similar problem, and found the problem is in the +CONTENTS in > the corresponding folder under /var/db/pkg/ . > It's caused by an empty @pkgdep line here. > I don't know what went wrong when the +CONTENTS file was created. But > delete all these empty @pkgdep lines solved my problem. > > Cheers, > Henry Worked for me too! Thanks a lot, I never would have thought to have tried that. ___ 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: 7.1 Panic on degraded disk w/mpt
On Monday 09 February 2009 1:13:08 am Charles Sprickman wrote:
> Howdy,
>
> I dug around and can't find a PR on this, and the only other report I saw
> was in this mailing list post that has no replies:
>
> http://www.nabble.com/7.1-BETA2-panic-on-mpt-degrade-td20183173.html
>
> The hardware is a Dell PowerEdge 860 with the Dell/LSI SAS5 controller:
> mpt0: port 0xec00-0xecff mem
> 0xfe9fc000-0xfe9f,0xfe9e-0xfe9e irq 16 at device 8.0 on pci2
> mpt0: MPI Version=1.5.13.0
>
> The panic is repeatable by forcing the array into a degraded state.
>
> Here's my best shot at getting info out of kgdb:
>
> [r...@uniweb /home/spork]# cd /usr/obj/usr/src/sys/BWAY7/
> [r...@uniweb /usr/obj/usr/src/sys/BWAY7]# kgdb kernel.debug
> /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> This GDB was configured as "i386-marcel-freebsd"...
>
> Unread portion of the kernel message buffer:
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x14
> fault code = supervisor read, page not present
> instruction pointer = 0x20:0xc044b09b
> stack pointer = 0x28:0xe6ee5b80
> frame pointer = 0x28:0xe6ee5b9c
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 17 (swi2: cambio)
> trap number = 12
> panic: page fault
> cpuid = 0
> Uptime: 3m7s
> Physical memory: 3575 MB
> Dumping 94 MB: 79 63 47 31 15
>
> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
> /boot/kernel/acpi.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/acpi.ko
> #0 doadump () at pcpu.h:196
> 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) list *0xc044b09b
> 0xc044b09b is in xpt_done (/usr/src/sys/cam/cam_xpt.c:4832).
> 4827if ((done_ccb->ccb_h.func_code & XPT_FC_QUEUED) != 0) {
> 4828/*
> 4829 * Queue up the request for handling by our SWI
handler
> 4830 * any of the "non-immediate" type of ccbs.
> 4831 */
> 4832sim = done_ccb->ccb_h.path->bus->sim;
> 4833switch (done_ccb->ccb_h.path->periph->type) {
> 4834case CAM_PERIPH_BIO:
> 4835TAILQ_INSERT_TAIL(&sim->sim_doneq,
&done_ccb->ccb_h,
> 4836 sim_links.tqe);
Can you 'p done_ccb->ccb_h.path' and if that is not 0, 'p
done_ccb->ccb_h.path.bus'?
--
John Baldwin
___
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: Backport of glxsb(4) to RELENG_6
Le Thu, 12 Feb 2009 22:34:43 +0100, Lars Engels : Hi, > I just tried it, but I get this message: > glxsb0: mem > 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 > glxsb0: cannot allocate DMA memory of 32768 bytes (12) I think you are very low on memory and the driver cannot allocate his DMA-able buffer (error 12=ENOMEM) This is not really a bug. But i've found another problem related to the taskqueue. I'm doing a fake driver to be able to test on a vmware machine. ___ 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 :-(
Guy Helmer wrote: FWIW, I think I have tracked down the changes just prior to 7.1-RELEASE that is causing my Supermicro dual Xeon machines to wedge. I did the binary search between 2008-10-02 and 2008-11-24 without reproducing any lockups, and then I went on to search between 2008-11-24 and 2009-01-04. An SMP kernel build from 2008-12-22 (r186409) sources was stable for over two weeks; a kernel built from 2008-12-29 (r186590) sources wedged in under 24 hours under moderate load. It appears that the significant changes between r186409 and r186590 were r186552 (delphij - reverted ATA changes) and r186535/r186534 (delphij - reverted bce changes). My machines don't have bce interfaces, so I suspect the ATA changes. Never mind. I'm stepping back through older kernels and finding that the hangs are now occurring in kernels that had seemed to be stable... Guy ___ 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: HEADS UP: Major CAM performance regression
On Fri, 2009-02-13 at 03:55 -0700, Scott Long wrote: > All, > > A major performance regression was introduced to the CAM subsystem in > FreeBSD 7.1. The following configurations are known to be affected: > > VMWare ESX > VMWare Fusion > (using bt or lsilogic controller options) > HP CISS RAID > Some MPT-SAS combinations with SATA drives attached > (Includes Dell SAS5/ir, but not PERC5/PERC6). > > Pure SCSI and SAS subsystems likely are NOT affected. Any hardware > that uses the 'ata' driver is also definitely NOT affected. To > determine if your installation is affected, run the following command as > root: > > camcontrol tags da0 > > Substitute 'da0' with another appropriate drive device number, if > needed. Note that this ONLY AFFECTS 'da' DEVICES. If your disks are > 'ad' devices, they are NOT affected. > > The result from running this command should be an output similar to the > following: > > (pass0:mpt0:0:8:0): device openings: 255 > > If, instead, it reports a value of '1', you are likely affected. Note > that it may be normal for USB memory devices to report a low number. > Also, many legacy SCSI disks, and devices that are not disks, may also > be expected to report a low number. > > The effect of this problem is that only one I/O command will be issued > to the controller and disk at a time, instead of overlapping multiple > commands in parallel. This causes significantly higher latency in > servicing moderate and heavy I/O workloads, leading to very poor > performance. Performance can be easily compared by downgrading to > FreeBSD 7.0. > > I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN > revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few > days once I've gotten confirmation that the fix works and doesn't cause > any adverse side-effects. Anyone wanting to help in this validation > effort should apply the attached patch to their kernel source tree and > recompile. Please contact me directly by email to report if the problem > is fixed for you. > > If the validation process goes smoothly, I will work with the release > engineering team to turn this fix into an official errata update for > FreeBSD 7.1. > > Thanks in advance for your help. > > Scott > Hi Scott I have one da0 device, a USB attached hard disk: umass0: on uhub6 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) camcontrol shows: > $ sudo camcontrol tags da0 (pass0:umass-sim0:0:0:0): device openings: 1 Is that to be expected? This is RELENG_7 from October '08: FreeBSD strangepork.mintel.co.uk 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Oct 22 02:25:56 BST 2008 r...@sweetpork.pc.mintel.co.uk:/usr/FreeBSD/RELENG_7/obj/usr/FreeBSD/RELENG_7/src/sys/STRANGEPORK i386 Thanks 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"
Re: fun with if_re
On Fri, 13 Feb 2009 20:39:55 +0900 Pyun YongHyeon wrote about Re: fun with if_re: PY> Ok, try attached patch. Thanks, building new images right now. I'll be back later (next week). cu Gerrit ___ 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: Upgrade from 32-bit to AMD-64?
> Sure, it's possible, given sufficient toolchain knowledge, time, and > skills, but it's not a sensible thing to do aside from experimentation > and learning purposes. Theres an intermediate method between upgrading in place and doing a full re-install which si what I used when I did this. 1) Install amd64 onto a completely separate bootable drive (USB will do). On that one do a 'make buildworld', 'make buildkernel'. 2) Take down the machine you mant to upgrade - boot it off the USB drive. When booted off the USb drive mount the orignal '/' somewhere. 3) Do a 'make installkernel' and 'make installworld' with DESTDIR=/oldslah to install the 64 bit OS onto the old drive. I also rewrote the boot sectors on the old slash drive too. 4) Reboot - it should come up amd64 with the old config fine. I have done this a couple of time to convert from 32 to 64 bit installs. The beauty is that it preserves the config. I would note, however, that in my case I did de-install all the packages and re-installed them afterwards, so I was then running full 64 bit. but it works, and the machine is only down for a few minutes. -pete. ___ 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: fun with if_re
On Fri, Feb 13, 2009 at 11:41:43AM +0100, Gerrit K?hn wrote:
> On Fri, 13 Feb 2009 19:24:00 +0900 Pyun YongHyeon wrote
> about Re: fun with if_re:
>
> PY> > I had to reboot some of the machines meanwhile and could do some
> PY> > further testing. One strange thing I noticed is that the
> PY> > re-interfaces often do not come up in a working state after
> PY> > rebooting. Strangely, I see network traffic floating around via
> PY> > tcpdump, but not even ping works. This state often goes away when
> PY> > playing around with the interface (sometimes ifconfig down/up helps,
> PY> > sometimes disabling some of the additional features like txc/rxc),
> PY> > but I cannot make out a reproducible behaviour so far. When the
> PY> > interface leaves this strange state it seems to work fine
> PY> > afterwards. Any clues?
>
> PY> Does this happen on latest if_re.c/if_rlreg.h? I guess jkim fixed
> PY> this type of problem in r187483. If that have no effect please let
> PY> me know.
>
> It happens on both versions: the old one from 11th Dec 08 I still had, and
> the new one I built with the patches you recommended about a week ago.
> if_re is 1.151 2009/01/20 20:22:28 jkim, if_rlreg is 1.94 2009/01/20
> 20:22:28 jkim for the latter.
>
Ok, try attached patch.
Index: sys/dev/re/if_re.c
===
--- sys/dev/re/if_re.c (revision 187352)
+++ sys/dev/re/if_re.c (working copy)
@@ -158,6 +158,8 @@
/* Tunables. */
static int msi_disable = 1;
TUNABLE_INT("hw.re.msi_disable", &msi_disable);
+static int prefer_iomap = 0;
+TUNABLE_INT("hw.re.prefer_iomap", &prefer_iomap);
#define RE_CSUM_FEATURES(CSUM_IP | CSUM_TCP | CSUM_UDP)
@@ -1131,26 +1133,36 @@
pci_enable_busmaster(dev);
devid = pci_get_device(dev);
- /* Prefer memory space register mapping over IO space. */
- sc->rl_res_id = PCIR_BAR(1);
- sc->rl_res_type = SYS_RES_MEMORY;
- /* RTL8168/8101E seems to use different BARs. */
- if (devid == RT_DEVICEID_8168 || devid == RT_DEVICEID_8101E)
- sc->rl_res_id = PCIR_BAR(2);
+ /*
+ * Prefer memory space register mapping over IO space.
+ * Because RTL8169SC does not seem to work when memory mapping
+ * is used always activate io mapping.
+ */
+ if (devid == RT_DEVICEID_8169SC)
+ prefer_iomap = 1;
+ if (prefer_iomap == 0) {
+ sc->rl_res_id = PCIR_BAR(1);
+ sc->rl_res_type = SYS_RES_MEMORY;
+ /* RTL8168/8101E seems to use different BARs. */
+ if (devid == RT_DEVICEID_8168 || devid == RT_DEVICEID_8101E)
+ sc->rl_res_id = PCIR_BAR(2);
+ } else {
+ sc->rl_res_id = PCIR_BAR(0);
+ sc->rl_res_type = SYS_RES_IOPORT;
+ }
sc->rl_res = bus_alloc_resource_any(dev, sc->rl_res_type,
&sc->rl_res_id, RF_ACTIVE);
-
- if (sc->rl_res == NULL) {
+ if (sc->rl_res == NULL && prefer_iomap == 0) {
sc->rl_res_id = PCIR_BAR(0);
sc->rl_res_type = SYS_RES_IOPORT;
sc->rl_res = bus_alloc_resource_any(dev, sc->rl_res_type,
&sc->rl_res_id, RF_ACTIVE);
- if (sc->rl_res == NULL) {
- device_printf(dev, "couldn't map ports/memory\n");
- error = ENXIO;
- goto fail;
- }
}
+ if (sc->rl_res == NULL) {
+ device_printf(dev, "couldn't map ports/memory\n");
+ error = ENXIO;
+ goto fail;
+ }
sc->rl_btag = rman_get_bustag(sc->rl_res);
sc->rl_bhandle = rman_get_bushandle(sc->rl_res);
___
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"
HEADS UP: Major CAM performance regression
All, A major performance regression was introduced to the CAM subsystem in FreeBSD 7.1. The following configurations are known to be affected: VMWare ESX VMWare Fusion (using bt or lsilogic controller options) HP CISS RAID Some MPT-SAS combinations with SATA drives attached (Includes Dell SAS5/ir, but not PERC5/PERC6). Pure SCSI and SAS subsystems likely are NOT affected. Any hardware that uses the 'ata' driver is also definitely NOT affected. To determine if your installation is affected, run the following command as root: camcontrol tags da0 Substitute 'da0' with another appropriate drive device number, if needed. Note that this ONLY AFFECTS 'da' DEVICES. If your disks are 'ad' devices, they are NOT affected. The result from running this command should be an output similar to the following: (pass0:mpt0:0:8:0): device openings: 255 If, instead, it reports a value of '1', you are likely affected. Note that it may be normal for USB memory devices to report a low number. Also, many legacy SCSI disks, and devices that are not disks, may also be expected to report a low number. The effect of this problem is that only one I/O command will be issued to the controller and disk at a time, instead of overlapping multiple commands in parallel. This causes significantly higher latency in servicing moderate and heavy I/O workloads, leading to very poor performance. Performance can be easily compared by downgrading to FreeBSD 7.0. I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few days once I've gotten confirmation that the fix works and doesn't cause any adverse side-effects. Anyone wanting to help in this validation effort should apply the attached patch to their kernel source tree and recompile. Please contact me directly by email to report if the problem is fixed for you. If the validation process goes smoothly, I will work with the release engineering team to turn this fix into an official errata update for FreeBSD 7.1. Thanks in advance for your help. Scott Index: cam_xpt.c === --- cam_xpt.c (revision 188569) +++ cam_xpt.c (revision 188570) @@ -6143,10 +6143,9 @@ xpt_schedule(periph, priority); return; } - xpt_release_ccb(done_ccb); - softc->action = PROBE_TUR_FOR_NEGOTIATION; - xpt_schedule(periph, priority); - return; + + csio->data_ptr = NULL; + /* FALLTHROUGH */ } case PROBE_SERIAL_NUM_1: ___ 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"
[7-STABLE] failure during buildworld
Hey everybody :) I'm having a small issue compiling 7-STABLE... during make buildworld, this error occurs: ===> gnu/lib/libstdc++ (depend) ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/cpu/generic/atomicity_mutex/atomicity.h atomicity.cc ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/gcc/unwind-generic.h unwind.h rm -f .depend mkdep -f .depend -a-DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I. /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libmath/stubs.c /usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/libiberty/cp-demangle.c mkdep -f .depend -a /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/bitmap_allocator.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/pool_allocator.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/mt_allocator.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/codecvt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/compatibility.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/complex_io.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ctype.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/debug.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/debug_list.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/functexcept.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/globals_io.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_failure.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_init.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_locale.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/limits.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale_init.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale_facets.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/localename.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/stdexcept.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/strstream.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/tree.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/allocator-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/concept-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/fstream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ext-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/iostream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/misc-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ostream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/sstream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/streambuf-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/streambuf.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/string-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/valarray-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/wlocale-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/wstring-inst.cc atomicity.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/codecvt_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/collate_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/darwin/ctype_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/messages_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/monetary_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/numeric_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/time_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/io/basic_file_stdio.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/c_locale.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_op.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsup
Re: fun with if_re
On Fri, 13 Feb 2009 19:24:00 +0900 Pyun YongHyeon wrote about Re: fun with if_re: PY> > I had to reboot some of the machines meanwhile and could do some PY> > further testing. One strange thing I noticed is that the PY> > re-interfaces often do not come up in a working state after PY> > rebooting. Strangely, I see network traffic floating around via PY> > tcpdump, but not even ping works. This state often goes away when PY> > playing around with the interface (sometimes ifconfig down/up helps, PY> > sometimes disabling some of the additional features like txc/rxc), PY> > but I cannot make out a reproducible behaviour so far. When the PY> > interface leaves this strange state it seems to work fine PY> > afterwards. Any clues? PY> Does this happen on latest if_re.c/if_rlreg.h? I guess jkim fixed PY> this type of problem in r187483. If that have no effect please let PY> me know. It happens on both versions: the old one from 11th Dec 08 I still had, and the new one I built with the patches you recommended about a week ago. if_re is 1.151 2009/01/20 20:22:28 jkim, if_rlreg is 1.94 2009/01/20 20:22:28 jkim for the latter. cu Gerrit ___ 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: fun with if_re
On Fri, Feb 13, 2009 at 10:19:10AM +0100, Gerrit K?hn wrote: > On Thu, 5 Feb 2009 17:28:04 +0900 Pyun YongHyeon wrote > about Re: fun with if_re: > > PY> > I did build new nanobsd images with these patches meanwhile and will > PY> > start using them today. However, as it has worked without problems > PY> > for weeks with the buggy version before, I will not be able to say > PY> > if it is really working until next month or so. Or do you know any > PY> > method to reliably > PY> > PY> That's fine. > > > I had to reboot some of the machines meanwhile and could do some further > testing. One strange thing I noticed is that the re-interfaces often do > not come up in a working state after rebooting. Strangely, I see > network traffic floating around via tcpdump, but not even ping works. > This state often goes away when playing around with the interface > (sometimes ifconfig down/up helps, sometimes disabling some of the > additional features like txc/rxc), but I cannot make out a reproducible > behaviour so far. When the interface leaves this strange state it seems to > work fine afterwards. Any clues? > Does this happen on latest if_re.c/if_rlreg.h? I guess jkim fixed this type of problem in r187483. If that have no effect please let me know. ___ 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: 7.1 Panic on degraded disk w/mpt
Charles Sprickman said: >Howdy, > >I dug around and can't find a PR on this, and the only other report I saw >was in this mailing list post that has no replies: > >http://www.nabble.com/7.1-BETA2-panic-on-mpt-degrade-td20183173.html > >The hardware is a Dell PowerEdge 860 with the Dell/LSI SAS5 controller: >mpt0: port 0xec00-0xecff mem >0xfe9fc000-0xfe9f,0xfe9e-0xfe9e irq 16 at device 8.0 on pci2 >mpt0: MPI Version=1.5.13.0 > >The panic is repeatable by forcing the array into a degraded state. I think this is PR 130330. http://www.freebsd.org/cgi/query-pr.cgi?pr=130330&cat= I am trying to get another test machine available - the machines I had have gone into production with 7.0 installed. (Apologies if this email doesn't appear correctly, done what I can!) ___ 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"
"The LOR page" is back
Hi, in case you find a LOR, want to report it or want to see if it's known or find out more about it... you can go and check "The LOR page" again. It's up on a temporary setup (so in case it's not avail come back a bit later) until I can finally move the web elsewhere. The URL has stayed the same: http://sources.zabbadoz.net/freebsd/lor.html The page has a few instructions and links to further information. You may want to read them before doing anything else to help everybody. Thanks! /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ 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: zfs crashes with nfs and snapshots
On Wed, 11 Feb 2009 19:55:11 +0200 Jaakko Heinonen wrote about Re: zfs crashes with nfs and snapshots: JH> This is likely the issue described in this message: JH> http://lists.freebsd.org/pipermail/freebsd-fs/2008-October/005217.html Yes, this looks very much like it. JH> The nfs fix has been committed to head and stable/7 (7.1-RELEASE has JH> the fix). The fix prevents system from panicing but you still can't JH> access the snapshot directory with readdirplus enabled nfs clients. As JH> a workaround you can disable readdirplus support if your nfs client JH> allows it. Ok, I will upgrade to 7.1-stable asap. The client was Linux 2.6.25, I cannot say if it uses readdirplus and if I could disable that (the manpage says nothing about it at all, but I will look into that further). Thanks for the hint. cu Gerrit ___ 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: fun with if_re
On Thu, 5 Feb 2009 17:28:04 +0900 Pyun YongHyeon wrote about Re: fun with if_re: PY> > I did build new nanobsd images with these patches meanwhile and will PY> > start using them today. However, as it has worked without problems PY> > for weeks with the buggy version before, I will not be able to say PY> > if it is really working until next month or so. Or do you know any PY> > method to reliably PY> PY> That's fine. I had to reboot some of the machines meanwhile and could do some further testing. One strange thing I noticed is that the re-interfaces often do not come up in a working state after rebooting. Strangely, I see network traffic floating around via tcpdump, but not even ping works. This state often goes away when playing around with the interface (sometimes ifconfig down/up helps, sometimes disabling some of the additional features like txc/rxc), but I cannot make out a reproducible behaviour so far. When the interface leaves this strange state it seems to work fine afterwards. Any clues? cu Gerrit ___ 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: Upgrade from 32-bit to AMD-64?
Hi, When have done this, MySQL is OK but Berkley and PostgreSQL need dump/restore. /glz --On February 13, 2009 2:53:13 -0500 Mike Andrews wrote: Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl Denninger wrote: [...] I guess I need to schedule the 2-3 hours of downtime. the reason for this, by the way, is that I have a dbms app on there that is getting too RAM hungry for its own good (its a Quadcore CPU) and I'm up against the RAM limit for 32-bit code. The board will support more but 32-bit code won't; ergo, the only way to get beyond this is to go to 64-bit. Oh wait! One thing you wanted to know is that, some database *can* have different on-disk format for 32-bit and 64-bit binaries. Be sure to have a dump handy. Last time I hit this on a MySQL "upgrade" between two servers, and I end up using its replication functionality. The operation took longer time than I expected at the beginning. For what it's worth, I did an in-place source upgrade on our MySQL server (for the same lack-of-memory reason) and didn't have any on-disk format problems. In fact later on when troubleshooting data corruption problems that turned out to be bad hardware, I switched between 32-bit and 64-bit mysqld binaries without rebooting or dumping/reimporting the database. BUT... there was no replication involved. It wouldn't surprise me if the binlog or relay logs were in an architecture specific format. InnoDB and MyISAM tables don't appear to be. This was over a year ago though, so test on a scratch box first and you may save yourself a bit of downtime. The upgrade is a pain, and does have a lot of potential foot-shooting, and you have to immediately recompile ALL of your installed ports (and anything else not built from ports) to avoid mixing 32-bit and 64-bit shared libraries... and that rebuilding ports time is where most of your downtime comes from if it's a production box. If you're feeling lucky, the procedure's in the list archives somewhere and the super-short version is you turn your swap partition into a temporary amd64 root filesystem, installworld/kernel into that, boot into that, then mount and installworld/kernel on top of the old i386 root filesystem from there, then boot into it and recompile all your ports (after reclaiming your swap partition for swap). Or, the way I did it last time was to boot into a PXE diskless FreeBSD/amd64 install and use that to mount/install over the i386 stuff. Definitely practice on a scratch system first. :) -- Mike Andrews Server Monkey Fark, Inc mandr...@fark.com ___ 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" ... the future isMobile Goran Lowkrantz System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Luleå, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ... ___ 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"
