Re: The MFC process...
>(And sorry to pick on Matt, heh.) Trent. You can pick on me all you like. I'll get to it when I can. Or won't. I have 3 kids and three mortgages at present (no they're not related), so I tend to be distracted from socially meaningful projects. ___ 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: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write
Matthew Fleming wrote:
As an aside, this is a quad-core in one package CPU (an X3363). On both
this box and a similar one with an X5470, console messages continue to
print out after "the system has been halted - press any key to reboot" -
in particular, the shutdown makes a bunch of the "behind the scenes" man-
agement stuff like the virtual keyboard and monitor appear. Plugging or
unplugging USB devices will go through the whole deal of detecting and
making their service available.
Oops, youre right that other CPUs are running.
The stop_cpus() call is only made if kdb is entered. doadump() is called out o
f boot() which comes later. At Isilon weve been running with a patch that does
stop_cpus() pretty close to the front of panic(9).
As an design decision it seems reasonable to call stop_cpus() early in panic(9)
simply because most causes for panic means something unexpected, and the soone
r the other CPUs arent running the more likely it is that they dont do more dam
age, leaving the system in a more useful state for dump or {g,d}db analysis. T
his should be done before dump or entering kdb.
Im ccing -current@ since I would like a small discussion of moving the stop_cpu
s() to earlier in panic. If this change is agreeable I can roll up a patch and
test it on CURRENT. Im not sure yet how much of the other panic-related chang
es we have made at Isilon would be required.
Work along this lines has been done at Panasas. We were planning on
put it back to the community. There turns out to be lots of edge cases
by changing this that we're still sorting thru.
___
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: SCSI error during boot
Just so you know... after having done a large number of SCSI target mode implementations and having seen what initiators do, it's Microsoft that is the closest to actually adhering to and using the SCSI standards correctly. On 7/20/07, Torfinn Ingolfsen <[EMAIL PROTECTED]> wrote: On Fri, 20 Jul 2007 23:43:35 +0200 "Uffe R. B. Andersen" <[EMAIL PROTECTED]> wrote: > That's nice to know, though I didn't expect it to be critical, as the > disk has worked well for all 8 years, running with Windows 2000 and > XP. IMHO, you should never use "working on win..." as a statement to say that some hardware is a) working b) compliant with a standard Just my two cents (having seen too much of broken hw and standards on win through the years). -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is read-write nullfs safe?
I use it all the time for compiles on top of nfs On 6/18/07, Rong-en Fan <[EMAIL PROTECTED]> wrote: I'm running 6.2-RELEASE, and I am wondering if using nullfs w/ rw is safe in a production environment? My impression is that ro nullfs is ok, but not rw. Is this still the case? Regards, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can I change probe order of mpt controllers?
FWIW, IMO- don't wire- use glabel instead. On 5/25/07, Scott Long <[EMAIL PROTECTED]> wrote: Vivek Khera wrote: > On May 25, 2007, at 11:22 AM, Scott Long wrote: > >> Look in /sys/conf/NOTES for a long discussion on wiring SCSI device >> order. > > Thanks! That looks like it should do the trick. I'm assuming those go > into /boot/loader.conf or do they go into the kernel config file > itself? They look like loader.conf entries, but I'm not 100% sure on that. They can be compiled into the kernel in the hints file (like GENERIC.hints) or it can be put into /boot/loader.conf. > > Also, any word on the adaptec monitoring program? I'm still interested > in that, but my new solution is just to push the raid external and use a > fibre card... which brought up this issue :-) > I'll follow up in private on this. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [releng_5 tinderbox] failure on sparc64/sparc64
Sorry- my bad. I'll fix shortly. On 5/10/07, FreeBSD Tinderbox <[EMAIL PROTECTED]> wrote: TB --- 2007-05-10 14:42:44 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2007-05-10 14:42:44 - starting RELENG_5 tinderbox run for sparc64/sparc64 TB --- 2007-05-10 14:42:44 - cleaning the object tree TB --- 2007-05-10 14:43:10 - checking out the source tree TB --- 2007-05-10 14:43:10 - cd /tinderbox/RELENG_5/sparc64/sparc64 TB --- 2007-05-10 14:43:10 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2007-05-10 14:56:20 - building world (CFLAGS=-O -pipe) TB --- 2007-05-10 14:56:20 - cd /src TB --- 2007-05-10 14:56:20 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2007-05-10 15:40:18 - generating LINT kernel config TB --- 2007-05-10 15:40:18 - cd /src/sys/sparc64/conf TB --- 2007-05-10 15:40:18 - /usr/bin/make -B LINT TB --- 2007-05-10 15:40:18 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2007-05-10 15:40:18 - cd /src TB --- 2007-05-10 15:40:18 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu May 10 15:40:18 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/isp/isp.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/isp/isp_freebsd.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/isp/isp_library.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/isp/isp_target.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/isp/isp_pci.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prot
Re: Dell SAS5 Performance Issue
I've been trying to get one in my lab. I also am completely saturated with two jobs and a new infant (which is why I'm responding to this at 0100) and was trying to get a box in my lab that evidenced te behaviour. If I get stuck when I actually get time to chase this, I'll ask- thanks. On 4/24/07, J. Martin Petersen <[EMAIL PROTECTED]> wrote: Matthew Jacob wrote: >> >> Is there any news on the performance of this card? >> > > I personally have not been able to reproduce the problem. It seems to > occur whether in Integrated Raid or not. It seems to be related to > specific backplanes and drives. It's an important problem to solve I > agree. We have a HP Proliant DL140 g3 that exhibits this (or a somewhat related) problem, to which we can give you remote access (including remote KVM) if that helps? Cheers, Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell SAS5 Performance Issue
Is there any news on the performance of this card? I personally have not been able to reproduce the problem. It seems to occur whether in Integrated Raid or not. It seems to be related to specific backplanes and drives. It's an important problem to solve I agree. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scsi/mpt problem with latest source
> > > > (xpt0:mpt0:0:-1:-1): reset bus periph:sim:channel:target:lun target == lun == -1 == wildcard, so the initial bus reset applies to a nexus for all targets and luns on that channel on that sim (mpt0) on that periph (xpt0) would you mind to tell why it happens and this "-1" values ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scsi/mpt problem with latest source
this reset bus didn't and do not happen with some day older sources: > > (xpt0:mpt0:0:-1:-1): reset bus Well, don't worry about it. It's always been happening. no, I do not boot verbose Thanks. I'll make this message show up under 'bootverbose' only., > > ... > > da0 at mpt0 bus 0 target 0 lun 0 > > da1 at mpt0 bus 0 target 1 lun 0 > > > > > > > > -- > > > > João > > > > > > > > > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada > > segura. Service fornecido pelo Datacenter Matik > > https://datacenter.matik.com.br > > ___ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada > segura. Service fornecido pelo Datacenter Matik > https://datacenter.matik.com.br -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scsi/mpt problem with latest source
pleasep pooint out what the error is, and are you booting verbose? On 4/1/07, JoaoBR <[EMAIL PROTECTED]> wrote: with new sources I get an mpt error which is not present with sources from march 28 mpt0: port 0xdc00-0xdcff mem 0xfd7e-0xfd7f,0xfd7c-0xfd7d irq 16 at device 4.0 on pci1 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.2.14.0 ... (xpt0:mpt0:0:-1:-1): reset bus ... da0 at mpt0 bus 0 target 0 lun 0 da1 at mpt0 bus 0 target 1 lun 0 -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell SAS5 Performance Issue
On 4/1/07, Richard Tector <[EMAIL PROTECTED]> wrote: Matthew Jacob wrote: > On 3/27/07, Richard Tector <[EMAIL PROTECTED]> wrote: >> Matthew Jacob wrote: >> > It's been seen before but the fix isn't know yet. >> > >> > On 3/27/07, Richard Tector <[EMAIL PROTECTED]> wrote: >> >> I'm suffering from very slow write performance on a Dell PowerEdge >> 860 >> >> with the SAS5/IR controller (mpt driver) running either >> 6.2-RELEASE or >> >> 6.2-STABLE with sources from yesterday. The controller hosts 2 >> Western >> >> Digital 320GB SATA disks in a RAID1 configuration. >> >> Reads approach 65MB/s however writes appear extremely slow, in the >> >> region of 6-7MB/s with a dd and a blocksize of 1MB all the way >> down to >> >> about 300KB/s while extracting a ports snapshot. >> >> >> >> It was suggested to me that perhaps write caching has been >> disabled on >> >> the controller however no options exist within the BIOS >> configuration to >> >> view/adjust *any* caching options. >> >> >> >> Has anyone else experienced this issue? If so how did they resolve >> it? >> >> Also, is there any way to toggle the caching settings from FreeBSD? >> A perhaps unrealted issue: I've noticed a large number of messages being produced by the mpt driver after boot occuring approximately every 90 seconds. Apr 1 15:51:43 moses kernel: mpt0: mpt_cam_event: 0x14 Apr 1 15:51:43 moses kernel: mpt0: Unhandled Event Notify Frame. Event 0x14 (ACK not required). Apr 1 15:53:19 moses kernel: mpt0: mpt_cam_event: 0x14 Apr 1 15:53:19 moses kernel: mpt0: Unhandled Event Notify Frame. Event 0x14 (ACK not required). Any thoughts anyone? Is there any way to find out what the events correspond to? MPI spec, instantiated in MPILIB MPI_EVENT_IR_RESYNC_UPDATE internal raid resync update? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell SAS5 Performance Issue
not at the momeny- it's really that I won't have time until april On 3/27/07, Richard Tector <[EMAIL PROTECTED]> wrote: Matthew Jacob wrote: > It's been seen before but the fix isn't know yet. > > On 3/27/07, Richard Tector <[EMAIL PROTECTED]> wrote: >> I'm suffering from very slow write performance on a Dell PowerEdge 860 >> with the SAS5/IR controller (mpt driver) running either 6.2-RELEASE or >> 6.2-STABLE with sources from yesterday. The controller hosts 2 Western >> Digital 320GB SATA disks in a RAID1 configuration. >> Reads approach 65MB/s however writes appear extremely slow, in the >> region of 6-7MB/s with a dd and a blocksize of 1MB all the way down to >> about 300KB/s while extracting a ports snapshot. >> >> It was suggested to me that perhaps write caching has been disabled on >> the controller however no options exist within the BIOS configuration to >> view/adjust *any* caching options. >> >> Has anyone else experienced this issue? If so how did they resolve it? >> Also, is there any way to toggle the caching settings from FreeBSD? >> >> Regards, >> >> Richard Tector >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "[EMAIL PROTECTED]" >> Thank you for the quick reply. Is there any information I could obtain that would be of use to you in tracking this one down? Regards, Richard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell SAS5 Performance Issue
It's been seen before but the fix isn't know yet. On 3/27/07, Richard Tector <[EMAIL PROTECTED]> wrote: I'm suffering from very slow write performance on a Dell PowerEdge 860 with the SAS5/IR controller (mpt driver) running either 6.2-RELEASE or 6.2-STABLE with sources from yesterday. The controller hosts 2 Western Digital 320GB SATA disks in a RAID1 configuration. Reads approach 65MB/s however writes appear extremely slow, in the region of 6-7MB/s with a dd and a blocksize of 1MB all the way down to about 300KB/s while extracting a ports snapshot. It was suggested to me that perhaps write caching has been disabled on the controller however no options exist within the BIOS configuration to view/adjust *any* caching options. Has anyone else experienced this issue? If so how did they resolve it? Also, is there any way to toggle the caching settings from FreeBSD? Regards, Richard Tector ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fibre channel cards
Generally speaking, the LSI-Logic cards are faster, at least for 2Gb, in terms of IOPS. However, the LSI-Logic firmware is less capable of coping with complicated topologies and the mpt(4) driver is less mature than isp(4). Another thing to keep in mind is that for new cards (as opposed to 'EBay' cards) that LSI is half the port cost of QLogic. On 3/8/07, Claus Guttesen <[EMAIL PROTECTED]> wrote: > Are there any other fibre channel cards supported on FreeBSD? > > What card would one recommend to connect to an external RAID array > for running a fairly busy database (several million inserts/selects/ > updates per day)? I've tried qlogic's 2310 and haven't had any issue with those. I did recompile the kernel and included ispfw which is commented out by default in GENERIC. I don't know whether they perform better or worse than hba's from LSI. regards Claus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help with QLogic FC problem diagnosis (da0:isp0:0:0:0): lost device
On 2/5/07, Eduardo Meyer <[EMAIL PROTECTED]> wrote: On 2/5/07, Matthew Jacob <[EMAIL PROTECTED]> wrote: > Helpful information would be: > > a) Release > b) Connection Topology > > It looks like you're going through a switch. Your short term solution > will be to zone your box and the CX300 together excluding all else. > > A longer term solution is for me to MFC the new SAN evaluation code > which is a bit less harsh. You are right, I am going through a switch. It is a 6.2-STABLE as of Feb 2nd. Is this code scheduled to be MFC'd? Yes, when it's got just a bit more mileage on it and I have time to monitor breakage that might occur. This is also with 24XX support. *Probably* toward the end of this month. As Wilko says, zoning is worth it unless you're explicitly sharing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help with QLogic FC problem diagnosis (da0:isp0:0:0:0): lost device
Helpful information would be: a) Release b) Connection Topology It looks like you're going through a switch. Your short term solution will be to zone your box and the CX300 together excluding all else. A longer term solution is for me to MFC the new SAN evaluation code which is a bit less harsh. On 2/5/07, Eduardo Meyer <[EMAIL PROTECTED]> wrote: Hello gentlemen, I have a QLogic FC card in a FreeBSD, connected to a CX300 storage which sometimes looses connection with no aparent reason. If someone had lived a similar problem or know of something that would help diagnose the cause, I would like to hear. When the problem happens all I get in the logs is: Feb 5 01:01:37 mailsrvr kernel: isp0: Name Server Database Changed Feb 5 01:01:37 mailsrvr kernel: isp0: Firmware State Ready> Feb 5 01:01:37 mailsrvr kernel: isp0: Target 126 (Loop 0x7e) Port ID 0xfe (role (none)) Arrived Feb 5 01:01:37 mailsrvr kernel: Port WWN 0x200500051e034ad8 Feb 5 01:01:37 mailsrvr kernel: Node WWN 0x10051e034ad8 Feb 5 01:01:37 mailsrvr kernel: isp0: 2Gb link speed/s Feb 5 01:01:37 mailsrvr kernel: isp0: Loop ID 255, Port ID 0x10500, Loop State 0x2, Topology 'F Port' Feb 5 01:01:37 mailsrvr kernel: isp0: Target 255 (Loop 0xff) Port ID 0x10500 (role Initiator) Arrived Feb 5 01:01:37 mailsrvr kernel: Port WWN 0x21e08b925d0e Feb 5 01:01:37 mailsrvr kernel: isp0: Name Server Database Changed Feb 5 01:01:37 mailsrvr kernel: isp0: Firmware State Ready> Feb 5 01:01:37 mailsrvr kernel: isp0: Target 126 (Loop 0x7e) Port ID 0xfe (role (none)) Arrived Feb 5 01:01:37 mailsrvr kernel: Port WWN 0x200500051e034ad8 Feb 5 01:01:37 mailsrvr kernel: Node WWN 0x10051e034ad8 Feb 5 01:01:37 mailsrvr kernel: isp0: 2Gb link speed/s Feb 5 01:01:37 mailsrvr kernel: isp0: Loop ID 255, Port ID 0x10500, Loop State 0x2, Topology 'F Port' Feb 5 01:01:37 mailsrvr kernel: isp0: Target 255 (Loop 0xff) Port ID 0x10500 (role Initiator) Arrived Feb 5 01:01:37 mailsrvr kernel: Port WWN 0x21e08b925d0e Feb 5 01:01:37 mailsrvr kernel: Node WWN 0x20e08b925d0e Feb 5 01:01:37 mailsrvr kernel: isp0: Fabric Device @ PortID 0x10400 Feb 5 01:01:37 mailsrvr kernel: isp0: Fabric Device @ PortID 0x10500 Feb 5 01:01:37 mailsrvr kernel: isp0: Target 0 (Loop 0x1) Port ID 0x1 (role Target) Departed Feb 5 01:01:37 mailsrvr kernel: Port WWN 0x500601603022db3d Feb 5 01:01:37 mailsrvr kernel: Node WWN 0x50060160b022db3d Feb 5 01:01:37 mailsrvr kernel: (da0:isp0:0:0:0): lost device Feb 5 01:01:37 mailsrvr kernel: isp0: Retained login of Target 1 (Loop ID 0x2) Port 0x10400 and later, FreeBSD freezes (sometimes it panics). It is not very often that it happens, and it is under completly random circunstances (sometimes high load, sometimes the lowest load, on different hours, etc). -- === Eduardo Meyer pessoal: [EMAIL PROTECTED] profissional: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Interrupt (SCSI?) hang on 4.x
Brute force things to try, IMO: a) Try a different (non-adaptec) SCSI controller b) Run non-SMP c) Swap motherboard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange behavior of ioapic on PDSME motherboard (was: LSI 53C1030/mpt(4) problem)
. I see. BTW, I confirmed that mpt worked on the November snapshot except the data transfer rate was 6.6MB/s. Is it worth trying the latest current? Just fixed, I think, as of last night. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LSI 53C1030/mpt(4) problem
- 2006 Nov 7-CURRENT snapshot probes the two HDDs case, but the HDDs are recognized as very slow devices such as 6MB/s, and accessing it makes the box freeze, too. The 6MB/s thing I'm working on now. I have no clue about the other issues at this time. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SunFire X4100 MPT Issues 6.2 RC1
[i'm on vacation now] Hmm- I thought I put in code so you should only see one of those. I'll check this out when I get back next week. On 11/21/06, Dave <[EMAIL PROTECTED]> wrote: We have a new SunFire X4100 box and so I figured I would try 6.2 RC1 on it. Everything seems to work with the exception of the following messages when the disk has some medium to heavy use. > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x03 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x04 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x03 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x04 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x03 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x04 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x03 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x04 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x03 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x04 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x04 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x03 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x04 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x03 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x04 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x03 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x03 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x04 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x03 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x04 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x03 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x04 Depth 65 > mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x03 Depth 65 So are these something to be concerned about? Secondly, are there any issues I should be concerned about running 6.2 on this hardware? dmesg of i386 verbose boot can be found here: http://wiki.nostrum.com/~daved/sunfire-4100.dmesg.txt I get the same messages when running amd64 port as well. Thanks, -- Dave ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sio driver sucks
YMMV and your message is content free. I use sio all the time as a [EMAIL PROTECTED] w/o any problems. On 11/12/06, Sergey Matveychuk <[EMAIL PROTECTED]> wrote: Do you know an old sio driver is hardly usable? There are many silo overflows, working with a terminal device is a nightmare. There was a report about one crash with a message about a spinlock holed more than 5 seconds (there is no core dump because it has not repeated). After a discussion in a Russian FIDO group I've change it on uart and the problems gone. I think a default driver should be changed from sio to uart until it will be fixed. -- Dixi. Sem. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Re: Qlogic 2340 problems
This is actually very very interesting to me. Flashing the BIOS *shouldn't* matter, but this is now the second (unrelated) incident I've heard where it does in very odd ways. No- on this- thank *you*. It's a path I would have not have thought to take and try and now will. On 10/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: We tried updating the cards firmware to an older version thinking that maybe the version it came with broke something since an identical card with an older firmware worked. After flashing the card it started to work. Flashed it to the latest version to see if it would fail again and it continued to work. *sigh* The good news, I am working. The bad news is I am not sure what was really wrong. Thanks for you help, Dave On 10/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On 10/10/06, Matthew Jacob <[EMAIL PROTECTED]> wrote: > > That's an odd one. It means that the DMA of the ICB failed. > > > > Three questions: > > > > a) Tell me more about this system > > Supermicro PDSMi Motherboard, 1G of RAM, Pentium D 3.4GHz CPU, 80G > SATA hard drive in a 1U chassis. > > http://www.supermicro.com/products/system/1U/5015/SYS-5015M-MR.cfm > > > b) Is this still a problem for the latest RELENG_6 branch changes? > > Have not tried yet. I am compiling it now and will give it a go. I > have another system that has the same card running 6.1 release that is > working. I am going to take it down tonight and look for differences. > > > c) Can you try a test kernel? > > Yes. The system is new and I have only loaded the OS and just started > testing to make sure all hardware worked before fully configuring the > box. I have remote serial console, remote KVM, and remote power to > the box so its a good box to play on. > > > > > On 10/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > I having problems getting this card to attach in FreeBSD 6.1. dmesg > > > shows the following: > > > > > > Qlogic ISP Driver, FreeBSD Version 5.9, Core Version 2.10 > > > isp0: port 0x4000-0x40ff mem > > > 0xed20-0xed200fff irq 24 at device 1.0 on pci3 > > > isp0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xed20 > > > isp0: using Memory space register mapping > > > ioapic1: routing intpin 0 (PCI IRQ 24) to vector 49 > > > isp0: [GIANT-LOCKED] > > > isp0: Board Type 2312, Chip Revision 0x2, loaded F/W Revision 3.3.6 > > > isp0: 839 max I/O commands supported > > > isp0: NVRAM Port WWN 0x21e08b8fa3b0 > > > isp0: Mailbox Command 'INIT FIRMWARE' failed (HOST INTERFACE ERROR) > > > > > > BIOS has been enabled in the card and the module ispfw has been > > > loaded. Card works in Windows XP. Not sure what to try next. Card > > > is hooked to a Brocade Silkworm 300 switch. Disks I am trying to see > > > are on an Apple Xserve RAID box. > > > > > > Thanks for you time, > > > Dave > > Dave > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Qlogic 2340 problems
That's an odd one. It means that the DMA of the ICB failed. Three questions: a) Tell me more about this system b) Is this still a problem for the latest RELENG_6 branch changes? c) Can you try a test kernel? On 10/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I having problems getting this card to attach in FreeBSD 6.1. dmesg shows the following: Qlogic ISP Driver, FreeBSD Version 5.9, Core Version 2.10 isp0: port 0x4000-0x40ff mem 0xed20-0xed200fff irq 24 at device 1.0 on pci3 isp0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xed20 isp0: using Memory space register mapping ioapic1: routing intpin 0 (PCI IRQ 24) to vector 49 isp0: [GIANT-LOCKED] isp0: Board Type 2312, Chip Revision 0x2, loaded F/W Revision 3.3.6 isp0: 839 max I/O commands supported isp0: NVRAM Port WWN 0x21e08b8fa3b0 isp0: Mailbox Command 'INIT FIRMWARE' failed (HOST INTERFACE ERROR) BIOS has been enabled in the card and the module ispfw has been loaded. Card works in Windows XP. Not sure what to try next. Card is hooked to a Brocade Silkworm 300 switch. Disks I am trying to see are on an Apple Xserve RAID box. Thanks for you time, Dave ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Recommendations for a serial port card you can actually BUY?
I would recommend staying with FreeBSD-5. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2
Just to add a data point: I just upgraded feral.com to the latest RELENG_6 branch. I have a dual port em for internal networks and I've never seen the problems reported. Also, for -current, things have now been stable again for the last week or so for em on multiple machines (most of which have dual em i/f's) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DELL CX300 storage
Or LSI-Logic. On 9/29/06, Wilko Bulte <[EMAIL PROTECTED]> wrote: On Fri, Sep 29, 2006 at 06:01:25PM -0300, Eduardo Meyer wrote.. > How sad :~ > > But thank you for the quick reply. I hope bsdstats initiative may help > somehow this kind of problem. All this said, I think you will find a Qlogic FC HBA will happily talk to your EMC CX! > >No, there is no Emulex FC driver for FreeBSD. I don't know about the > >current situation, but Emulex used to only supply docs under NDA. > > > >Qlogic was/is much easier in this respect. > > > >Wilko Bulte [EMAIL PROTECTED] > > > > -- > === > Eduardo Meyer > pessoal: [EMAIL PROTECTED] > profissional: [EMAIL PROTECTED] > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" --- end of quoted text --- -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: iSCSI HBAs
There was some interest in QLogic's part a couple of years ago to get 4000 support and they contacted me, but I was pretty much uninterested in it as a project. Go poke them again and see if they want to try. Why do you think an iSCSI HBA would be of any benefit to anything other than the target mode side as a server? On 9/15/06, Robert Blayzor <[EMAIL PROTECTED]> wrote: Anyone know if there is a working driver for either the QLogic QLA4050C or Adaptec 7211C iSCSI HBAs? I know there is a software based initiator in the works, but having a driver for the iSCSI HBA's would provide a great alternative to running diskless or FC SAN. -- Robert Blayzor, BOFH INOC, LLC rblayzor\@(inoc.net|gmail.com) PGP: 0x66F90BFC @ http://pgp.mit.edu Key fingerprint = 6296 F715 038B 44C1 2720 292A 8580 500E 66F9 0BFC Press Ctrl-Alt-Del now for IQ test. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Several issues on Dell 1950/2950 servers (6-STABLE and 7-CURRENT)
On 6-STABLE, those "Error 22" messages on boot, show up too slowly, one character at a time, at about one line every 30 seconds, which delays the boot process on almost 20 (twenty) minutes. After that huge delay, the disc information is shown and the file system is fsck'ed, as usually. However, disabling APIC, eliminates this delay. On 7-CURRENT, there is not such delay, even though APIC was enabled. Oh, okay. Not an mpt issue (I'm somewhat narrowly focussed). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Several issues on Dell 1950/2950 servers (6-STABLE and 7-CURRENT)
If by "all the time" you mean every time certain disk operations are performed (tarball extraction, files download...), then, yes. All the time. Otherwise, no error shows up. Hmm. Okay. I'll work on this. > > Insofar as the Error 22- that's normal to see those for verbose > booting. They should be more informative as to why those are > occurring. > You're right. Those messages are evident only while verbose booting, so, I'm not really concerned about them but the huge delay on booting (up to 18 min) they represent on 6-STABLE. Hmm. I'll have to dig back thru the mail here but I don't get this. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Several issues on Dell 1950/2950 servers (6-STABLE and 7-CURRENT)
Oops- mangled reply. On 9/9/06, Matthew Jacob <[EMAIL PROTECTED]> wrote: > > is gone, but a new error message appears as often as the former, > and under the same circumstances: > > > mpt0: QUEUE_FULL: Bus 0x00 Target 0x00 Depth 128 Do you see these all the time? If so I'll have to connect up some logic to take and shut down openings to match the Depth field- although this is a step I've been resisting. Insofar as the Error 22- that's normal to see those for verbose booting. They should be more informative as to why those are occurring. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Several issues on Dell 1950/2950 servers (6-STABLE and 7-CURRENT)
is gone, but a new error message appears as often as the former, and under the same circumstances: > mpt0: QUEUE_FULL: Bus 0x00 Target 0x00 Depth 128 -- Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Several issues on Dell 1950/2950 servers (6-STABLE and 7-CURRENT)
Thank you :-) I am myself considering hardware from the same vendor and I assume others are as well, so I appreciate the effort. It's a Tier One vendor- you can rest assured that FreeBSD will support it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Several issues on Dell 1950/2950 servers (6-STABLE and 7-CURRENT)
> > Yup, sounds like a mess here. But is there a solution or workaround rather than just concluding? Well, I've collected some info and am trying to sort through all of the stories. There certainly is something wrong with recent mpt(4) and I'm trying to figure out what. It affects some people's h/w (not mine when I tested prior to making the checkins). So, I'm trying to come up with a solution, yes. *Much* regards -matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Several issues on Dell 1950/2950 servers (6-STABLE and 7-CURRENT)
The OS booted up and the SAS controller was now detected and supported by the mpt(4) driver: --- mpt0: port 0xec00-0xecff mem 0xfc4fc000-0xfc4f, 0xfc4e-0xfc4e irq 64 at device 8.0 on pci2 mpt0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xec00 mpt0: Reserved 0x4000 bytes for rid 0x14 type 3 at 0xfc4fc000 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.5.12.0 --- And the related errors showed up immediately, for the first time: --- mpt0: mpt_cam_event: 0x16 mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). mpt0: mpt_cam_event: 0x12 mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required). mpt0: mpt_cam_event: MPI_EVENT_SAS_DEVICE_STATUS_CHANGE mpt0: mpt_cam_event: MPI_EVENT_SAS_DEVICE_STATUS_CHANGE mpt0: mpt_cam_event: 0x16 mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). -- These are device arrival events. When the bootstrap process reached the SCSI probe, there were no activity on the screen for about five minutes, so I was forced to use the power off button, and after rebooting, the same symptoms were evident, so I rebooted the machine once again, this time in verbose mode. This debug information was being printed on the screen, one character at time, at about 1 char/sec: (probe8:mpt0:0:8:0): error 22 What's at target 8? It isn't happy for a variety of reasons. Oh- I see from below- it's an SES instance that drops dead if given something at lun 0. (probe8:mpt0:0:8:0): Unretryable Error --- pass0 at mpt0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-5 device > As a workaround, I disabled the APICs (hint.apic.0.disabled), and that ~15 minutes delay at boot up, now was gone. Fine. (BTW, 7-CURRENT has the same problem, but without that huge delay) Do you have APIC disabled for 7-CURRENT also? Once I was logged in the server, I proceeded to populate my ports tree, by using portsnap(8), so, when I extracted the tarball (portsnap extract), there was a lot of the following error message, at about 1 message per second: mpt0: Unhandled Event Notify Frame. Event 0xe (ACK not required). Queue Full events from the SAS firmware. Once in a while, an error message like below, showed up: -- (da0:mpt0:0:0:0): WRITE(10). CDB: 2a 0 1 55 6f 5f 0 0 20 0 (da0:mpt0:0:0:0): CAM Status: SCSI Status Error (da0:mpt0:0:0:0): SCSI Status: Check Condition (da0:mpt0:0:0:0): UNIT ATTENTION asc:29,2 (da0:mpt0:0:0:0): Scsi bus reset occurred Somebody is reseeting the bus periodically. We (freebsd) aren't volitionally doing this that I'm aware of here. In order to perform those diagnostics, I had to install a SuSe Linux Enterprise Server 9, which was also shipped with this machine) Which is a good way of saying that LSI-Logic support isn't very evident on FreeBSD. After reinstalling FreeBSD, I logged remotely into the server, via ssh, and fetched the ports snapshot again and extracted once more. Suddenly, the screen activity ceased and the network connection timed out. Locally, on the server, there was a lot of mpt(4) errors and warnings. --- (da0:mpt0:0:0:0): CAM Status 0x18 (da0:mpt0:0:0:0): Retrying Command (... and about 500 more lines like those...) Hmm. --- And finally, those errors from mpt(4): --- request 0xc4c4a080:44717 timed out for ccb 0xc4e41400 (req->ccb 0xc4e41400) request 0xc4c4b430:44718 timed out for ccb 0xc4ca5800 (req->ccb 0xc4ca5800) request 0xc4c4cd80:44719 timed out for ccb 0xc4c52800 (req->ccb 0xc4c52800) (... and about 300 more lines like those ...) --- which were followed by the same number of lines like these: --- mpt0: completing timedout/aborted req 0xc4c4a080:44717 mpt0: completing timedout/aborted req 0xc4c4b430:44718 mpt0: completing timedout/aborted req 0xc4c4cd80:44719 --- and finishing with this line: --- mpt0: Timedout requests already complete. Interrupts may not be functioning. --- I've seen this on Supermicro EM64T in the past on 7-current, but that went away about 3-4 weeks ago. It really seemed to me that this was indeed an interrupt related problem. Yup, sounds like a mess here. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with QLogic 2312 FC controller on FreeBSD 4.11 stable
working with Erik on this now... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Losing confidence in FreeBSD 6.x in a loaded environment ... :(
Well, I have to say that I had to reboot my 6.1 gateway on Sunday. It was 5.X prior to this and never had to be rebooted. On 6/26/06, Marc G. Fournier <[EMAIL PROTECTED]> wrote: Okay, now this is getting ridiculous .. and for all those that have been helping me debug things over the past few days, this isn't a rant against "people", its a rant against the state of FreeBSD 6.x :( Its got SERIOUS problems. As easy as it is to 'blame the hardware', I'm up to my third FreeBSD 6.x system that is having problems now, all of which ran flawlessly under FreeBSD 4-STABLE under some serious load ... And by 'serious load' .. jupiter (the one that was giving me the SegFaults under those two kernels I tried) was up to 100 vServers running on it while I was clearning things off of pluto to upgrade her to 6.x ... and something like 209 days uptime ... Right now, I have 3 FreeBSD 4.x left in production, and 4 FreeBSD 6.x ... One 4.x server is running 87 vServers, has been up for 74 days now, and vmstat 5 shows: # vmstat 5 procs memory pagedisks faults cpu r b w avmfre flt re pi po fr sr da0 da1 in sy cs us sy id 3 5 0 3594432 228088 60 3 3 1 73 310 0 0 584 562 569 28 29 43 3 5 0 3578556 227384 546 0 1 7 592 0 0 18 434 1869 1647 7 11 83 2 5 0 3564464 225092 807 0 0 0 505 0 2 4 382 2698 2684 8 9 83 One of my 6.x just went down for the second time today ... locked up solid ... first time it did it today, it was hitting maxpipekva, which seems to be my biggest headache so far with 6.x ... Pluto, the one that we've been pretty much fighting over this past weekend, is running 69 vServers, 1363 processes, a loadavg <1 ... and I'm lucky to keep it running for 24 hours ... maxpipekva is set to: kern.ipc.maxpipekva: 67108864 - kern.ipc.pipekva: 35782656 It just doesn't feel like 6.x is as robust under loaded conditions as 4-STABLE was ... :( I don't expect anything to get fixed based on this email ... it was more to get off my chest about those that have been suggesting that I'm overloading the server(s) and causing the problems ... I loaded them worse under 4.x, with less problems ... hell, I got better uptimes under load when I was using unionfs then 6.x right now is giving me *without* any "funny mounts" :( Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [releng_5 tinderbox] failure on amd64/amd64
Ah- never mind- my bad. On 6/8/06, Matthew Jacob <[EMAIL PROTECTED]> wrote: I'm assuming that this is just stale information for the Tinderbox. There is no mpt_freebsd.c defined in sys/conf/files any more. On 6/8/06, FreeBSD Tinderbox <[EMAIL PROTECTED]> wrote: > TB --- 2006-06-08 21:32:20 - tinderbox 2.3 running on freebsd-stable.sentex.ca > TB --- 2006-06-08 21:32:20 - starting RELENG_5 tinderbox run for amd64/amd64 > TB --- 2006-06-08 21:32:20 - cleaning the object tree > TB --- 2006-06-08 21:32:48 - checking out the source tree > TB --- 2006-06-08 21:32:48 - cd /tinderbox/RELENG_5/amd64/amd64 > TB --- 2006-06-08 21:32:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src > TB --- 2006-06-08 21:42:11 - building world (CFLAGS=-O -pipe) > TB --- 2006-06-08 21:42:11 - cd /src > TB --- 2006-06-08 21:42:11 - /usr/bin/make -B buildworld > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> stage 5.1: building 32 bit shim libraries > TB --- 2006-06-08 22:51:08 - generating LINT kernel config > TB --- 2006-06-08 22:51:08 - cd /src/sys/amd64/conf > TB --- 2006-06-08 22:51:08 - /usr/bin/make -B LINT > TB --- 2006-06-08 22:51:08 - building LINT kernel (COPTFLAGS=-O -pipe) > TB --- 2006-06-08 22:51:08 - cd /src > TB --- 2006-06-08 22:51:08 - /usr/bin/make buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Thu Jun 8 22:51:08 UTC 2006 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > [...] > @ -> /src/sys > machine -> /src/sys/amd64/include > awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h > awk -f @/tools/makeobjops.awk @/kern/device_if.m -h > awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h > ln -s /obj/amd64/src/sys/LINT/opt_cam.h opt_cam.h > ln -s /obj/amd64/src/sys/LINT/opt_ddb.h opt_ddb.h > make: don't know how to make mpt_freebsd.c. Stop > *** Error code 2 > > Stop in /src/sys/modules. > *** Error code 1 > > Stop in /obj/amd64/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2006-06-08 22:52:50 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2006-06-08 22:52:50 - ERROR: failed to build lint kernel > TB --- 2006-06-08 22:52:50 - tinderbox aborted > TB --- 1.38 user 4.38 system 4829.62 real > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [releng_5 tinderbox] failure on amd64/amd64
I'm assuming that this is just stale information for the Tinderbox. There is no mpt_freebsd.c defined in sys/conf/files any more. On 6/8/06, FreeBSD Tinderbox <[EMAIL PROTECTED]> wrote: TB --- 2006-06-08 21:32:20 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2006-06-08 21:32:20 - starting RELENG_5 tinderbox run for amd64/amd64 TB --- 2006-06-08 21:32:20 - cleaning the object tree TB --- 2006-06-08 21:32:48 - checking out the source tree TB --- 2006-06-08 21:32:48 - cd /tinderbox/RELENG_5/amd64/amd64 TB --- 2006-06-08 21:32:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2006-06-08 21:42:11 - building world (CFLAGS=-O -pipe) TB --- 2006-06-08 21:42:11 - cd /src TB --- 2006-06-08 21:42:11 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2006-06-08 22:51:08 - generating LINT kernel config TB --- 2006-06-08 22:51:08 - cd /src/sys/amd64/conf TB --- 2006-06-08 22:51:08 - /usr/bin/make -B LINT TB --- 2006-06-08 22:51:08 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2006-06-08 22:51:08 - cd /src TB --- 2006-06-08 22:51:08 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jun 8 22:51:08 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] @ -> /src/sys machine -> /src/sys/amd64/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h ln -s /obj/amd64/src/sys/LINT/opt_cam.h opt_cam.h ln -s /obj/amd64/src/sys/LINT/opt_ddb.h opt_ddb.h make: don't know how to make mpt_freebsd.c. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-06-08 22:52:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-06-08 22:52:50 - ERROR: failed to build lint kernel TB --- 2006-06-08 22:52:50 - tinderbox aborted TB --- 1.38 user 4.38 system 4829.62 real ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggestions for Adaptec SAS AIC9410
The mpt driver was just MFC'd, but that won't help the adaptec issue. There is a remote chance that somebody I'm doing work for will want a FreeBSD driver for the adaptec card, but that won't be for a couple of months. It's a huge PITA- the SuperMicro boards are nice , but they don't get along with LSI-Logic. So, when I get SuperMicro, I pretty much get the ones with native SATA. On 6/5/06, Andy Dills <[EMAIL PROTECTED]> wrote: I'm trying to get a Supermicro 6024H-32R setup with 6.1, but I'm discovering that the Adaptec SAS AIC9410 controller isn't yet supported. I see one brief thread about it on this mailing list back in March, but no further mention or conclusive details. There was talk of MFCing the mpt driver...is anybody using this in production? I'd prefer to use FreeBSD, but I'm guessing I'm going to need to do SuSE for this box, which Adaptec provides drivers for. Thanks, Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HP DL145G2 SCSC Raid Controlle Q
> > mhh, isn't mpt only a SCSI controller (not a RAID controller)? Not in some configurations. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: contigmalloc() lameness (Re: boot problem in HP Proliant ML370 G4)
On Mon, 3 Apr 2006, Scott Long wrote: Matthew Jacob wrote: I must have missed something here. What's the problem that causes contigmalloc to be called here? If this is to do with > 4GB of memory, that was fixed in -CURRENT over a month ago. He's using 6.0-RELEASE. A reason to allow an MFC ? :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: contigmalloc() lameness (Re: boot problem in HP Proliant ML370 G4)
I must have missed something here. What's the problem that causes contigmalloc to be called here? If this is to do with > 4GB of memory, that was fixed in -CURRENT over a month ago. -Original Message- From: Ganbold [mailto:[EMAIL PROTECTED] Sent: Sunday, April 02, 2006 10:28 PM To: Kris Kennaway Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; freebsd-stable@FreeBSD.org Subject: Re: contigmalloc() lameness (Re: boot problem in HP Proliant ML370 G4) Kris Kennaway wrote: > On Mon, Apr 03, 2006 at 12:56:57PM +0900, Ganbold wrote: > >> Here is dmes.boot and pciconf output on FreeBSD-6.0-RELEASE. >> Boot takes 3-4 minutes after "da0: 140014MB (286749488 512 byte sectors: >> 255H 63S/T 17849C)" line and continues. >> I will try to upgrade again to 6.1-PRERELEASE later today. I did before >> and the problem still was there. >> > > The mpt driver calls contigmalloc in a way that takes ages to run > because it was poorly rewritten some time ago. Scottl partially fixed > it on 7.0 (after the problem became much worse there - it was taking > over 40 minutes instead of 4) but the change is not complete enough to > back-port yet. > I see. Yes, it eventually becomes up after 3-4 minutes. However what annoying is every time I reboot/restart the server I have to manually press "Enter" key. How can I resolve this issue? Is there any known solution? In any case I will try first RELENG_6 then CURRENT on this machine. thanks, Ganbold > Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [releng_5 tinderbox] failure on sparc64/sparc64
Too late. Scott beat me to it. On 2/5/06, Matthew Jacob <[EMAIL PROTECTED]> wrote: > Sigh. Sorry. I'm on it. > > > On 2/5/06, FreeBSD Tinderbox <[EMAIL PROTECTED]> wrote: > > TB --- 2006-02-05 11:55:13 - tinderbox 2.3 running on > > freebsd-stable.sentex.ca > > TB --- 2006-02-05 11:55:13 - starting RELENG_5 tinderbox run for > > sparc64/sparc64 > > TB --- 2006-02-05 11:55:13 - cleaning the object tree > > TB --- 2006-02-05 11:56:10 - checking out the source tree > > TB --- 2006-02-05 11:56:10 - cd /tinderbox/RELENG_5/sparc64/sparc64 > > TB --- 2006-02-05 11:56:10 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd > > -rRELENG_5 src > > TB --- 2006-02-05 12:06:15 - building world (CFLAGS=-O -pipe) > > TB --- 2006-02-05 12:06:15 - cd /src > > TB --- 2006-02-05 12:06:15 - /usr/bin/make -B buildworld > > >>> Rebuilding the temporary build tree > > >>> stage 1.1: legacy release compatibility shims > > >>> stage 1.2: bootstrap tools > > >>> stage 2.1: cleaning up the object tree > > >>> stage 2.2: rebuilding the object tree > > >>> stage 2.3: build tools > > >>> stage 3: cross tools > > >>> stage 4.1: building includes > > >>> stage 4.2: building libraries > > >>> stage 4.3: make dependencies > > >>> stage 4.4: building everything > > TB --- 2006-02-05 12:49:52 - generating LINT kernel config > > TB --- 2006-02-05 12:49:52 - cd /src/sys/sparc64/conf > > TB --- 2006-02-05 12:49:52 - /usr/bin/make -B LINT > > TB --- 2006-02-05 12:49:52 - building LINT kernel (COPTFLAGS=-O -pipe) > > TB --- 2006-02-05 12:49:52 - cd /src > > TB --- 2006-02-05 12:49:52 - /usr/bin/make buildkernel KERNCONF=LINT > > >>> Kernel build for LINT started on Sun Feb 5 12:49:52 UTC 2006 > > >>> stage 1: configuring the kernel > > >>> stage 2.1: cleaning up the object tree > > >>> stage 2.2: rebuilding the object tree > > >>> stage 2.3: build tools > > >>> stage 3.1: making dependencies > > >>> stage 3.2: building everything > > [...] > > isp_sbus.o(.text+0x16f8): In function `isp_sbus_dmasetup': > > : undefined reference to `isp_handle_index' > > isp_sbus.o(.text+0x1914): In function `isp_sbus_dmasetup': > > : undefined reference to `isp_put_request' > > isp_sbus.o(.text+0x1928): In function `isp_sbus_dmasetup': > > : undefined reference to `isp_put_extended_request' > > isp_sbus.o(.text+0x1944): In function `isp_sbus_dmateardown': > > : undefined reference to `isp_handle_index' > > *** Error code 1 > > > > Stop in /obj/sparc64/src/sys/LINT. > > *** Error code 1 > > > > Stop in /src. > > *** Error code 1 > > > > Stop in /src. > > TB --- 2006-02-05 12:57:07 - WARNING: /usr/bin/make returned exit code 1 > > TB --- 2006-02-05 12:57:07 - ERROR: failed to build lint kernel > > TB --- 2006-02-05 12:57:07 - tinderbox aborted > > TB --- 1.14 user 4.16 system 3713.75 real > > > > ___ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [releng_5 tinderbox] failure on sparc64/sparc64
Sigh. Sorry. I'm on it. On 2/5/06, FreeBSD Tinderbox <[EMAIL PROTECTED]> wrote: > TB --- 2006-02-05 11:55:13 - tinderbox 2.3 running on freebsd-stable.sentex.ca > TB --- 2006-02-05 11:55:13 - starting RELENG_5 tinderbox run for > sparc64/sparc64 > TB --- 2006-02-05 11:55:13 - cleaning the object tree > TB --- 2006-02-05 11:56:10 - checking out the source tree > TB --- 2006-02-05 11:56:10 - cd /tinderbox/RELENG_5/sparc64/sparc64 > TB --- 2006-02-05 11:56:10 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd > -rRELENG_5 src > TB --- 2006-02-05 12:06:15 - building world (CFLAGS=-O -pipe) > TB --- 2006-02-05 12:06:15 - cd /src > TB --- 2006-02-05 12:06:15 - /usr/bin/make -B buildworld > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > TB --- 2006-02-05 12:49:52 - generating LINT kernel config > TB --- 2006-02-05 12:49:52 - cd /src/sys/sparc64/conf > TB --- 2006-02-05 12:49:52 - /usr/bin/make -B LINT > TB --- 2006-02-05 12:49:52 - building LINT kernel (COPTFLAGS=-O -pipe) > TB --- 2006-02-05 12:49:52 - cd /src > TB --- 2006-02-05 12:49:52 - /usr/bin/make buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Sun Feb 5 12:49:52 UTC 2006 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > [...] > isp_sbus.o(.text+0x16f8): In function `isp_sbus_dmasetup': > : undefined reference to `isp_handle_index' > isp_sbus.o(.text+0x1914): In function `isp_sbus_dmasetup': > : undefined reference to `isp_put_request' > isp_sbus.o(.text+0x1928): In function `isp_sbus_dmasetup': > : undefined reference to `isp_put_extended_request' > isp_sbus.o(.text+0x1944): In function `isp_sbus_dmateardown': > : undefined reference to `isp_handle_index' > *** Error code 1 > > Stop in /obj/sparc64/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2006-02-05 12:57:07 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2006-02-05 12:57:07 - ERROR: failed to build lint kernel > TB --- 2006-02-05 12:57:07 - tinderbox aborted > TB --- 1.14 user 4.16 system 3713.75 real > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [releng_6 tinderbox] failure on sparc64/sparc64
I would think that the tinderboxes should run 100% the same flags as what normal release builds use. Nothing more, nothing less. What I would like to see is a pointer to a procedure and tools to make sure builds aren't broken. I've been refreshing my memory about email going back about 5 years, and at that time there was a lot of wrangle over people not doing adequate checking for at least syntactic correctness for multiple platforms. I certainly have broken a lot more than I would like lately, and part of this (other than being too stupid and hasty) came about because it wasn't actually obvious what would be a good pre-commit compile check for kernels for me to follow. At the very least I've now come up with: compile GENERIC (easy enough to do) compile LINT (this wasn't obvious how to make LINT) compile PAE (for i386 at least) Since the complaint of 5 years ago by many was that they didn't have alphas to compile on is still relatively true (that is, few people have more than one architecture) has been addressed in two ways (tinderbox, and cross-compilers), the issue should be better, but for three things I've observed: a) The tinderbox breakage is being treated as bad as stop ship type of bug rather than being informative as it should be. I feel I got roasted and slammed for what should have been simply a "hey- Matt- come fix this please!". b) It's instantly not obvious to me (being lazy and not having kept all my committer mail in a way I can find) how *I* can do a tinderbox run myself. c) Similarily, I don't know how to build a cross-build environment. I should, and I bet if grovel around a bit I can find out how to do so. The point here is that if well-meaning and moderately intelligent committers miss steps that are important to keeping the quality up, please point them at documentation that gives a reasonably coherent set of steps as to how to correct their errors. I'm sure that most of those who err will spend the extra late night hours to get it right then. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [releng_6 tinderbox] failure on sparc64/sparc64
On Thu, 2 Feb 2006, Matthew Jacob wrote: MJ>Is the tinderbox still failing? I haven't seen that mail- maybe I'm not on MJ>the list it's being sent to? You may look into either stable@ or spar64@ Ah. I'm subscribed to neither. Okay- thanks for the headsup that it's still broken. I have a slow 420R making its way thru an updated LINT tree right now. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [releng_6 tinderbox] failure on sparc64/sparc64
Hmm- I doesn't recall "name not mentioned" telling me about this earlier- perhaps he can dig up the mail as I haven't had any mail from him directly in years that I recall. Is the tinderbox still failing? I haven't seen that mail- maybe I'm not on the list it's being sent to? There are two complaints by the sparc64 complier- now that somebody (Marius) gave me useful information I will address it when I have a spare moment tomorrow. Insofar as inlining is concern- possibly so, but it demonstrably causes no compiler complaints in about 50 other contexts. My main concern at the moment is to make sure that the tinderbox failures are addressed and to pretty much ignore anything else from "name not mentioned". On Thu, 2 Feb 2006, Dag-Erling Smørgrav wrote: Scott Long <[EMAIL PROTECTED]> writes: I've been trying to reproduce this on my local hardware, but I can't trigger it. The ISP driver abuses the inline keyword. As I told mjacob earlier, the extensive inlining not only breaks the build, but probably hurts performance as well. (what gcc is complaining about, specifically, is that expanding calls to inlined functions causes isp_target_notify() to grow by more than 100%) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Alright you primitive screwheads, LISTEN UP!!
What an amusing rant. As far as I can tell, I've always been banned from your Inbox whether I called you BIll, Paul, Wpaul, or OMisterWizard! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can isp driver support Qlogic 2340 on FreeBSD5.x or later?
Yeah, sorry- the newer QLogic cards have firmware that has a different protocol that I haven't written the code for yet. In general, always load the firmware module as well. *EVENTUALLY* we'll be able to unload it and reclaim the member. On 5/2/05, Danny Braniss <[EMAIL PROTECTED]> wrote: > > On Mon, May 02, 2005 at 04:45:10PM +0300, Danny Braniss wrote.. > > > > Yes, the 234X cards have been supported for quite a while. > > > > > > > it seems not all of them: > > > it's a QLA2342/ISP2312 and im getting: > > > isp1: port 0x2400-0x24ff mem > > > 0xfe8e-0xfe8e0fff irq 24 at device 8.0 on pci3 > > > isp1: bad execution throttle of 0- using 16 > > > isp2: port 0x2000-0x20ff mem > > > 0xfe8f-0xfe8f0fff irq 27 at device 8.1 on pci3 > > > isp2: bad execution throttle of 0- using 16 > > > > > > Have you loaded the ispfw.ko firmware module? Matt tests the driver > > against that firmware, not against all the firmware revs Qlogic has > > released over time. > BINGO! > and i thought isp does the firmware update ... > > thanks, > danny > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can isp driver support Qlogic 2340 on FreeBSD5.x or later?
Yes, the 234X cards have been supported for quite a while. DELL has a clone card which up until recently wasn't supported. The 236X/63XX cards are not yet supported. On 4/14/05, wsk <[EMAIL PROTECTED]> wrote: > folks: > Can the Qlogic 2340 Fibre Channel card works on FreeBSD now? > DELL released a newest Server PE6850 with this card.thx > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: EOT tape handling changed?
I'm not sure what you're talking about here with this test program (deleted)- unless you've dorked with MAXPHYS defines, the maximum you can any tape record at is 64K. > > > I'm not sure that this is right. The NetBSD driver will do the same > > behaviour at this point. > > Maybe it has been changed too? Or maybe afbackup on NetBSD has problems > (however there is a trivial and universal fix for both cases, no problem) > as in FreeBSD now, even if sources of afbackup take NetBSD into account. > Can anybody try EOT handling in NetBSD in the reality? I'm sorry, I'm > afraid that I could not do this. I might. > > > The problem is that you cannot return a residual if you return an error. > > For tape drives that then write *partial* final records (e.g., if you > > have EEW off), you cannot know exactly what you wrote. Therefore, when > > Please, what is "EEW off"? Enable Early Warning- this allows you to get EOT notification prior to hard end of tape. Otherwise, you get a VOLUME OVERFLOW and lose data (usually). See below. > > you read things back, you end up with duplicated data when you do tape > > spanning. > > I'm not sure, if I see this problem too. If I understand correctly, > previous behaviour was that when write() was successful just partially, > it returned -1/ENOSPC, so some data could be duplicated on the next > tape. Now write() should return partial count, then zero and > then -1/ENOSPC... But the problem here is that you need a signifier. It's been a while since I worked on this stuff, so I had to go refrehs my memory- sorry if my story keeps changing. The model I'm trying to converge to has the following (if writing): If you got a VOLUME OVERFLOW, then you're at hard eot, so you latch up a residual, which is pointless because you're going to set ENOSPC. If you get EOM notification (Early Warning), then you mark EOM pending. Now- it turns out that for all the tape drives I tested that showed a non-zero residual after EOM notification that they were, actually, wrong. They did in fact finish writing the data out. So, in any case, this is where SA_FLAG_EOM_PENDING is set, deferring action until the *next* I/O. For 5.0-Current, the choice is then made to to make the signifier on the next I/O be setting residual to equal byte count- indicating that zero bytes had been written. To me these are the correct semantics. However, setting ENOSPC here is probably okay for -stable. The key point though is that SA_FLAG_EOM_PENDING is then cleared if there is no further I/O queued up. Additional I/O will get the same Early Warning error, but the I/O *will* complete (unless hard EOT is hit). So- to re-summarize: If you hit hard EOT, this reflects right away back to the application, who gets ENOSPC and stops writing. If you hit Early Warning, you get a signifier on the next write- but you're allowed to continue to write since the one *after* the signifier goes thru. Another issue then arises- should you allow I/O past Early Warning? That's the whole point of this funky dance. My take is that you *should* allow I/O (in order to write trailer records, should the application want to). A very similar mechanism was put in place on Solaris. From st(7): EOT Handling The Emulex drives have only a physical end of tape (PEOT); thus it is not possible to write past EOT. All other drives have a logical end of tape (LEOT) before PEOT to guarantee flushing the data onto the tape. The amount of storage between LEOT and PEOT varies from less than 1 Mbyte to about 20 Mbyte, depending on the tape drive. If EOT is encountered while writing an Emulex, no error is reported but the number of bytes transferred is 0 and no further writing is allowed. On all other drives, the first write that encounters EOT will return a short count or 0. If a short count is returned, then the next write will return 0. After a zero count is returned, the next write returns a full count or short count. A following write returns 0 again. It is important that the number and size of trailer records be kept as small as possible to prevent data loss. Therefore, writing after EOT is not recommended. It seems to me that in the process of doing this for FreeBSD, we run afoul of some applications who seem to expect perfect I/O up until hard EOT. This is similar in NetBSD where 'early warning' is disabled by default. So- sorry for the verbiage. We're left with a "what to do" type of issue now. Let me do a little testing with -stable modified to force ENOSPC instead of a zero i/o move count signifier- I'll let you know. > > PS: I have/had another problem with timeouts - what do you think about > increasing the standard value for SA_IO_TIMEOUT? In case of M2 from > Exabyte, there is SmartClean feature, that when there are too much > write error
Re: Intel PRO/1000F NIC & wx driver
I'll look at it when I next spend a couple of days on this NIC (hopefully next week). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HEADS UP! MFC's
On Fri, 27 Oct 2000, Mike Smith wrote: > > > > There are some things which are broken in -stable that need to be > > fixed (alpha booting, e.g.). We'll try to leave the world a better > > place for our efforts. > > -stable world builds, installs and boots on my pws433 as of earlier > today (with dfr's ata fix). Yes- same here. But what I want to do as the gating item for 4.2 is to make sure that the boot floppies work for all the models that we claim to support. Eh? -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Fibre Channel Controller
> > > 6) Fibrechannel drives do not consume 50% more than SCSI drives unless you > > > > What does this mean? > > Sorry, it was meant to be "50% more power". To be sure! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Fibre Channel Controller
> 3) Multi-Initiator on SCSI? Don't make me laugh. Every FC drive has two
> ports as standard. Multi-Initiator is built in.
A word of caution about this- there is a lot of buggy driver f/w for the
dual ports.
> 6) Fibrechannel drives do not consume 50% more than SCSI drives unless you
What does this mean?
> want to compare current SCSI drives with old FC ones.
>
> [...]
>
> 8) FC is bidirectional and is meant to be dual loop so really you have
> 400Mbytes per second if you want to compare numbers. By the time Ultra160
> is stable 2Gb FC links will be available. Where has SCSI to go then? 80Mhz
> I don't think so. 2Gb transceivers are readily available and 4Gb
> transceivers are well on their way.
No, wrong thinking here. This is theory. In practice unless you use
switches you don't have full duplex. I don't know of any FC card that has
the number of connectors to make it true dual-loop (2x{send,receive}), so
that argument is bogus.
A better point to note that the 2GB FC links are coming.
> So what would I buy for my PC, well UltraSCSI of course, unless
> gives me an FC cabinet. Then again if I was buying a couple of terabytes
> then I would go FC, mirroring (RAID1) not RAID5 because drives are cheap
> and write performance is better.
This is my conclusion too, but the figure of merit isn't a "couple of
terabytes", it's "numbers of addressable units".
-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
