Re: cvs commit: src/sys/netgraph/bluetooth/drivers/ubt ng_ubt.c ng_ubt_var.h
'yr welcome. I needed a kernel right away. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/cam cam_xpt.c
On Mon, 11 Sep 2006, Sam Leffler wrote: Matt Jacob wrote: mjacob 2006-09-11 17:34:28 UTC FreeBSD src repository Modified files: sys/cam cam_xpt.c Log: PR: 103130 Submitted by: Shusuke Shinomiya MFC after: 1 day This seems to be missing a commit msg. Yes, fat-fingered. However, the PR should suffice in this case. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/cam/scsi scsi_da.c
On Sat, 16 Sep 2006, Poul-Henning Kamp wrote: In message <[EMAIL PROTECTED]>, Matt Jacob writes : mjacob 2006-09-16 21:21:07 UTC FreeBSD src repository Modified files: sys/cam/scsi scsi_da.c Log: Don't allow attachment of disks that could cause GEOM to panic. The correct commit message would have been: Don't allow attachment of disks which we couldn't possibly do I/O from. The problem is that there is a fixed upper limit for the I/O transfer sizes we support (this should be fixed) and if the sectorsize is larger, we're hosed. Au contraire mon frere You can attach to the device and *then* set it's block size to something reasonable via mode select. Si ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/conf Makefile.sun4v files.sun4v options.sun4v src/sys/sun4v/compile .cvsignore src/sys/sun4v/conf DEFAULTS GENERIC GENERIC.hints MAC Makefile NOTES src/sys/sun4v/include _bus.h
| What kmacy really needs is the SAS disk in the special Sun carrier | that the T2000 needs. Same with the SunFire 4100. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/conf Makefile.sun4v files.sun4v options.sun4v src/sys/sun4v/compile .cvsignore src/sys/sun4v/conf DEFAULTS GENERIC GENERIC.hints MAC Makefile NOTES src/sys/sun4v/include _bus.h
One of the promises of SAS was that you could combine the benefit of SAS infrastructure (multipathing, channel bonding, and out-of-the-box connectivity) with the cost effectiveness of SATA. Of course, that already existed with Fibre Channel, so the migration to SAS hasn't been as swift as many had hoped. Storage purchasers and vendors are incredibly (over)conservative. That plus the fact that not even the SAS vendors (to my knowledge, as of about 9 months ago- stale info by now) have demonstrated working setups that have more than 4 SAS expanders. That *also* plus that fact that SAS drives are unattractive from a $/GB perspective while SATA drives are unattractive from a random IOPS perspective. This all combines to make people not *quite* ready to run with a SAS infrastructure. Before I left DataDomain I was looking into various interconnect technologies that get one out of the capacity of 12-16 drives with a CPU head. Up until now, this has been dominated by Fibre Channel as the only real choice, but dual path SAS connections through ~7 expanders to make a rack seemed to be a good bet, with SATA drives for apps that are driven by density, SAS drives for apps driven by IOPS. That gets you, for SATA drives, something on the order of 90 spindles, or something around 30-35 TB per rack what with sparing and RAID5 or RAID6. I expect that this might become attractive for the smaller data center stuff or where you can fit an app that actually can *use* all that data in one CPU head. FibreChannel is still going to be the choice where you have to interconnect more than one CPU head with your storage, or you have larger (e.g. > PB) needs. *Hopefully* iSCSI, or a less hampered replacement, will come in with 10Gb and kill Fibre Channel, but I don't expect that for a few years. I suppose that a PATA drive should work on a SAS controller if a SATA converter is used. It's also possible to put a Chevy Nova drive train into an Audi, given enough effort with a welding torch. I just wouldn't recommend it. It's a way to be able to flash SATA drives with new f/w using a Laptop and IDE PCI-Card connector. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/nfsclient nfs_vnops.c
So, inquiring minds want to know why defaults/rc.conf still sets this to 2 then. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/nfsclient nfs_vnops.c
On Sat, 14 Oct 2006, [EMAIL PROTECTED] wrote: So, inquiring minds want to know why defaults/rc.conf still sets this to 2 then. *smack*- I meant in RE_6. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/kern kern_exit.c
Are these changes why 9 out of ten reboots for me go into panic with: panic: signal pending ? On Sun, 22 Oct 2006, David Xu wrote: On Sunday 22 October 2006 08:14, Don Lewis wrote: On 21 Oct, David Xu wrote: davidxu 2006-10-21 23:59:15 UTC FreeBSD src repository Modified files: sys/kern kern_exit.c Log: Since revision 1.333 of kern_sig.c no longer uses P_WEXIT, the change opened a race window which can cause memory leak in signal queue. Here we free memory for signal queue when process state is set to PRS_ZOMBIE. Revision ChangesPath 1.291 +8 -2 src/sys/kern/kern_exit.c I wonder if the earlier change is what broke portupgrade after I upgraded from an August 31st version of current to yesterday's version. The symptoms were random processes dying from SIGHUP. It was easy to reproduce by just going to a port directory and running script foo make clean a few times. I'd randomly see make complain about a non-zero exit status from uname or some other sub-process. I tracked the problem back to the SIGHUP bit being set in td2's sigqueue in fork1(). As a workaround, I added a call to sigqueue_init() where td2 gets bzero'ed. Disappearing back into the void ... But I am still worrried by these signal changes, if an exiting process can be sent a signal, and msleep will interrupted in cleanup code, where the code will return to ? in normal case, code will return to userland, and signal will be removed and delivered, but if a thread is in exit1(), where the code can be returned to ? if a cleanup procedure is interrupted, isn't there is any resource leak or dead-loop if it is retried because signal is never removed ? David Xu ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/i386/isa clock.c src/sys/amd64/isa clock.c
Ooh, cool. This is crucial when you want to do a persistent 'failed' state for cheap machines with memory errors that you are using as appliances. Can you MFC these? peter 2007-06-15 22:58:14 UTC FreeBSD src repository Modified files: sys/i386/isa clock.c sys/amd64/isaclock.c Log: Prototype (but functional) Linux-ish /dev/nvram interface to the extra 114 bytes of cmos ram in the PC clock chip. The big difference between this and the Linux version is that we do not recalculate the checksums for bytes 16..31. We use this at work when cloning identical machines - we can copy the bios settings as well. Reading /dev/nvram gives 114 bytes of data but you can seek/read/write whichever bytes you like. Yes, this is a "foot, gun, fire!" type of device. Revision ChangesPath 1.232 +99 -0 src/sys/amd64/isa/clock.c 1.237 +99 -0 src/sys/i386/isa/clock.c ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/contrib/ipfilter/tools ipfstat.c
On Sun, 24 Jun 2007, Alexey Dokuchaev wrote: On Sun, Jun 24, 2007 at 04:39:12PM +, Darren Reed wrote: darrenr 2007-06-24 16:39:12 UTC FreeBSD src repository Modified files: contrib/ipfilter/tools ipfstat.c Log: ipfstat should parse "any" when used with -D/-S command line options PR: bin/113879 Submitted by: [EMAIL PROTECTED] Reviewed by:darrenr Isn't is kinda obvious that you review what you commit? :-) given the rate of errors in my own commits, I'd say that reviews had been lacking :-) ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/net if.c if_var.h src/sys/netinet in.c in_var.h
Cool. Can we put this in regression tests? ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netinet tcp_input.c tcp_usrreq.c
I know. I'm going to look at it more today. On Sun, 29 Jul 2007, Maxim Konovalov wrote: Thanks for fixing this. The whole tcpstates stuff is hackish. We need a better fix as the state reporting in the log message should not depend on TCPDEBUG. tb still fails at tcpstates. -- Maxim Konovalov ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netinet tcp_input.c tcp_usrreq.c
I'm not sure I *did* fix this- the tinderbox stuff is still falling opver. On Sun, 29 Jul 2007, Andre Oppermann wrote: Matt Jacob wrote: mjacob 2007-07-29 01:31:33 UTC FreeBSD src repository Modified files: sys/netinet tcp_input.c tcp_usrreq.c Log: Fix compilation problems- tcpstates is only available if TCPDEBUG is set. Approved by:re (in spirit) Thanks for fixing this. The whole tcpstates stuff is hackish. We need a better fix as the state reporting in the log message should not depend on TCPDEBUG. -- Andre ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netinet tcp_input.c tcp_usrreq.c
Sorry- I was a tired and cranky idiot. I have this fixed now, and will do a real universe run *and* ask re. The problem here is that the code is definitely ancient wanky- there's a const char *[] array in tcp_fsm.h that's compiled in iff TCPSTATES is defined. Various files include tcp_fsm.h and define TCPSTATES. However, what is getting the linker bugged is the line extern const char *tcpstates[]; that makes for a *different* definition of the object. The fix is to remove the 'extern' refs (tcp_usrreq doesn't need one, and spx_debug.c should do the TCPSTATES define like tcp_input && tcp_debug do). I know. I'm going to look at it more today. On Sun, 29 Jul 2007, Maxim Konovalov wrote: Thanks for fixing this. The whole tcpstates stuff is hackish. We need a better fix as the state reporting in the log message should not depend on TCPDEBUG. tb still fails at tcpstates. -- Maxim Konovalov ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netinet tcp_input.c tcp_usrreq.c
Here's what probably works. I'll do the test compiles.
Index: netinet/tcp_input.c
===
RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.366
diff -u -r1.366 tcp_input.c
--- netinet/tcp_input.c 29 Jul 2007 01:31:33 - 1.366
+++ netinet/tcp_input.c 29 Jul 2007 17:18:33 -
@@ -1573,15 +1573,9 @@
KASSERT(headlocked, ("%s: trimthenstep6: tcp_close.3: head "
"not locked", __func__));
if ((s = tcp_log_addrs(&tp->t_inpcb->inp_inc, th, NULL, NULL)))
{
-#ifdef TCPDEBUG
log(LOG_DEBUG, "%s; %s: %s: Received data after socket "
"was closed, sending RST and removing tcpcb\n",
s, __func__, tcpstates[tp->t_state]);
-#else
- log(LOG_DEBUG, "%s; %s: Received data after socket "
- "was closed, sending RST and removing tcpcb\n",
- s, __func__);
-#endif
free(s, M_TCPLOG);
}
tp = tcp_close(tp);
Index: netinet/tcp_usrreq.c
===
RCS file: /home/ncvs/src/sys/netinet/tcp_usrreq.c,v
retrieving revision 1.159
diff -u -r1.159 tcp_usrreq.c
--- netinet/tcp_usrreq.c29 Jul 2007 01:31:33 - 1.159
+++ netinet/tcp_usrreq.c29 Jul 2007 17:18:34 -
@@ -87,9 +87,6 @@
/*
* TCP protocol interface to socket abstraction.
*/
-#ifdef TCPDEBUG
-extern const char *tcpstates[];
-#endif
static int tcp_attach(struct socket *);
static int tcp_connect(struct tcpcb *, struct sockaddr *,
Index: netipx/spx_debug.c
===
RCS file: /home/ncvs/src/sys/netipx/spx_debug.c,v
retrieving revision 1.18
diff -u -r1.18 spx_debug.c
--- netipx/spx_debug.c 11 May 2007 10:38:34 - 1.18
+++ netipx/spx_debug.c 29 Jul 2007 17:18:34 -
@@ -69,6 +69,8 @@
#include
#include
+#defineTCPSTATES /* for logging */
+
#include
#include
Index: netipx/spx_debug.h
===
RCS file: /home/ncvs/src/sys/netipx/spx_debug.h,v
retrieving revision 1.17
diff -u -r1.17 spx_debug.h
--- netipx/spx_debug.h 11 May 2007 10:38:34 - 1.17
+++ netipx/spx_debug.h 29 Jul 2007 17:18:34 -
@@ -95,8 +95,6 @@
#ifdef _KERNEL
extern char *prurequests[];
extern char *sanames[];
-extern char *tcpstates[];
-
void spx_trace(short act, u_char ostate, struct spxpcb *sp, struct spx *si,
int req);
#endif
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netinet tcp_input.c tcp_usrreq.c
On Sun, 29 Jul 2007, Bjoern A. Zeeb wrote: On Sun, 29 Jul 2007, [EMAIL PROTECTED] wrote: Here's what probably works. I'll do the test compiles. If I am not wrong it will not. The follwoing two files have comments at the beginning to explain the changes. I don't like the extern char *tcpstates[] but it seems to be the best solution for now. No, that's what's actually wrong. tcpstates has to be static to honor the intent of the original author. If you want to do something extern then the actual tcpstates should go into tcp_debug.c. However, this is slightly less flexible in that the way it is now each source file can include this array simply by defining TCPSTATES (independent of TCPDEBUG as an option). This is all incredible microopt goop. The only reason I didn't just simply make this an always visible thing is that it really dates to all intents and purposes from the end of the PDP-11 era where the inclusion of this array or not was really worth worrying about. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netinet tcp_input.c tcp_usrreq.c
solution for now. No, that's what's actually wrong. tcpstates has to be static to honor the intent of the original author. If you want to do something extern then the actual tcpstates should go into tcp_debug.c. However, this is slightly less flexible in that the way it is now each source file can include this array simply by defining TCPSTATES (independent of TCPDEBUG as an option). It should go int tcp_input.c if any because that's the only file that always needs it now. If you do not have TCP there will be no tcp_input and TCPDEBUG will make no sense but there can be a tcp_input without TCPDEBUG/tcp_debug. It has been used with the extern in netipx since 1995. It is exposed to user space so moving it out of the header will break things. If you have any other better short term solution to not break anything I am happy but I could not see one. As said, I am not happy with the extern either. All of these statements seem to cancel each other out or are incorrec. I consider the subject closed as it is compiling a universe run right now. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netinet tcp_input.c tcp_usrreq.c
I believe I have it fixed and was just waiting for the different compiles to finish. I realize that I've inconvenienced you all by being slow in correcting this- and I do apologize. Except to DES. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netinet tcp_input.c tcp_usrreq.c
On Mon, 30 Jul 2007, Warner Losh wrote: [EMAIL PROTECTED] writes: All of these statements seem to cancel each other out or are incorrec. I consider the subject closed as it is compiling a universe run right now. Famous last words. As I've said far too many times before, 'make universe' is worthless. Now will you please fix this properly? Thank you for your opinion. However, make universe is not worthless. If doing one, and checking the output for errors, isn't sufficient to get tinderbox to not whine, then tinderbox is broken. Particularly since tinderbox is difficult to use (at least for me). Look -this is in some senses all of a side issue to getting this fixed. I've asked RE to let me check in a change and hopefully we can move on and then I'll try and figure out the latest ports version of tinderbox and see if it actually does what I need quicker. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/amd64/amd64 busdma_machdep.c mem.c mp_watchdog.c pmap.c trap.c src/sys/amd64/conf GENERIC src/sys/amd64/isa isa_dma.c src/sys/arm/arm busdma_machdep.c mem.c pmap.c src
eh? when I went to see what damage had been caused by this megachange I found no trace of it at all. Is this an April Fools mail? On Sun, 1 Apr 2007, Kris Kennaway wrote: kris2007-04-01 04:21:44 UTC FreeBSD src repository Modified files: sys/amd64/amd64 busdma_machdep.c mem.c mp_watchdog.c pmap.c trap.c sys/amd64/conf GENERIC sys/amd64/isaisa_dma.c sys/arm/arm busdma_machdep.c mem.c pmap.c sys/arm/xscale/i80321 i80321_aau.c i80321_dma.c sys/cam cam_xpt.c sys/cam/scsi scsi_cd.c scsi_ch.c scsi_da.c scsi_pass.c scsi_pt.c scsi_sa.c scsi_ses.c scsi_target.c sys/coda coda_fbsd.c sys/compat/freebsd32 freebsd32_misc.c sys/compat/linprocfs linprocfs.c sys/compat/linux linux_file.c linux_futex.c linux_getcwd.c linux_ioctl.c linux_misc.c linux_socket.c sys/compat/ndis subr_ndis.c subr_ntoskrnl.c sys/compat/svr4 svr4_misc.c svr4_stream.c svr4_stropts.h sys/conf NOTES options sys/contrib/dev/acpica acobject.h sys/contrib/dev/oltr if_oltr.c sys/contrib/ipfilter/netinet mlfk_ipl.c sys/dev/aac aac.c aac_cam.c sys/dev/acpica acpi.c acpi_dock.c sys/dev/advansys adv_eisa.c adv_isa.c adv_pci.c advansys.c adw_pci.c adwcam.c sys/dev/aha aha.c aha_isa.c aha_mca.c sys/dev/ahb ahb.c sys/dev/aic7xxx aic_osm_lib.c aic_osm_lib.h sys/dev/amd amd.c sys/dev/amr amr.c sys/dev/ar if_ar.c sys/dev/arcmsr arcmsr.c sys/dev/arl if_arl.c sys/dev/asr asr.c sys/dev/ata ata-all.c ata-chipset.c atapi-cam.c sys/dev/ath if_ath.c sys/dev/atkbdc psm.c sys/dev/awi awi.c sys/dev/bce if_bce.c if_bcereg.h sys/dev/bge if_bgereg.h sys/dev/bktr bktr_os.c msp34xx.c sys/dev/buslogic bt.c bt_eisa.c bt_isa.c bt_mca.c bt_pci.c sys/dev/ce if_ce.c sys/dev/ciss ciss.c sys/dev/cnw if_cnw.c sys/dev/cp if_cp.c sys/dev/cs if_cs.c sys/dev/ctau if_ct.c sys/dev/cx if_cx.c sys/dev/dc if_dc.c if_dcreg.h sys/dev/dconsdcons_crom.c dcons_os.c sys/dev/digi digi.c sys/dev/dpt dpt_eisa.c dpt_isa.c dpt_pci.c dpt_scsi.c sys/dev/drm drm-subprocess.pl drm_drv.c sys/dev/em if_em.c sys/dev/ex if_ex.c sys/dev/fatm if_fatm.c sys/dev/fb creator.c fb.c sys/dev/fdc fdc.c sys/dev/fe if_fe.c sys/dev/firewire fwdev.c fwdma.c fwohci.c fwohci_pci.c if_fwe.c if_fwip.c sbp.c sys/dev/fxp if_fxp.c sys/dev/hwpmchwpmc_mod.c sys/dev/ida ida.c ida_disk.c sys/dev/ie if_ie.c sys/dev/ieee488 ibfoo.c sys/dev/if_ndis if_ndis.c sys/dev/iicbus if_ic.c iic.c sys/dev/iir iir.c iir_ctrl.c iir_pci.c sys/dev/io iodev.c sys/dev/ips ips.c sys/dev/isp isp_freebsd.c isp_freebsd.h isp_sbus.c sys/dev/joy joy.c sys/dev/kbd kbd.c sys/dev/kbdmux kbdmux.c sys/dev/lge if_lge.c if_lgereg.h sys/dev/lmc if_lmc.h sys/dev/mcd mcd.c sys/dev/md md.c sys/dev/mem memdev.c sys/dev/mfi mfi.c sys/dev/mlx mlx.c mlx_disk.c sys/dev/mly mly.c sys/dev/mpt mpt.h mpt_cam.c mpt_raid.c sys/dev/mse mse.c sys/dev/nge if_ngereg.h sys/dev/nmdm nmdm.c sys/dev/nve if_nve.c sys/dev/ofw ofw_console.c openfirmio.c openpromio.c sys/dev/pbio pbio.c sys/dev/pccbbpccbb.c sys/dev/pci pci_user.c sys/dev/powermac_nvram powermac_nvram.c sys/dev/ppbusif_plip.c lpt.c pcfclock.c ppi.c sys/dev/ray if_ray.c sys/dev/re if_re.c sys/dev/rr232x os_bsd.h osm_bsd.c sys/dev/sbni if_sbni.c sys/dev/sbsh if_sbsh.c sys/dev/scd scd.c sys/dev/si si.c sys/dev/sk if_sk.c xmaciireg.h sys/dev/smbussmb.c sys/dev/sn if_snreg.h sys/dev/snc dp83932.c sys/dev/snp snp.c sys/dev/sound/isaad1816.c ess.c mss.c sb16.c sb8.c sys/dev/sound/midi sequencer.c sys/dev/sound/pciau88x0.c aureal.c cs4281.c csapcm.c emu10k1.c emu10kx.c envy24.c envy24ht.c fm801.c maestro.c solo.c t4dwave.c vibes.c sys/dev/sound/pcmdsp.c mixer.c sndstat.c sys/dev/speaker spkr.c sys/dev/sr if_sr.c sys/dev/streams streams.c sys/dev/sym sym_hipd.c sys/d
Re: cvs commit: src/sys/amd64/amd64 busdma_machdep.c mem.c mp_watchdog.c pmap.c trap.c src/sys/amd64/conf GENERIC src/sys/amd64/isa isa_dma.c src/sys/arm/arm busdma_machdep.c mem.c pmap.c src/sys/arm/
Arg- I meant '[EMAIL PROTECTED]:/home/ncvs'. I'm still seeing this as a bogus checkin The header for the mail from 'Kris' is: Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D770A13C43E; Sun, 1 Apr 2007 07:13:53 + (UTC) (envelope-from [EMAIL PROTECTED]) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 4E8751A4DAC; Sun, 1 Apr 2007 00:13:53 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 9EFC6517E2; Sun, 1 Apr 2007 03:13:52 -0400 (EDT) This is more like Paul Saab's IP address. freefall.freebsd.org? On Sun, 1 Apr 2007, Christoph Mallon wrote: Kris Kennaway wrote: On Sun, Apr 01, 2007 at 12:10:03AM -0700, [EMAIL PROTECTED] wrote: eh? when I went to see what damage had been caused by this megachange I found no trace of it at all. Is this an April Fools mail? Hmm, I think I might have screwed something up :( CVS meisters, please help! Maybe his CVS mirror just hasn't caught up yet. (-: ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/amd64/amd64 busdma_machdep.c mem.c mp_watchdog.c pmap.c trap.c src/sys/amd64/conf GENERIC src/sys/amd64/isa isa_dma.c src/sys/arm/arm busdma_machdep.c mem.c pmap.c src/sys/arm/
Hmm, that would explain some things. Paul? But this mail is also via that address. Sigh- one of these days I'll learn how to read PGP signatures. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/amd64/amd64 busdma_machdep.c mem.c mp_watchdog.c pmap.c trap.c src/sys/amd64/conf GENERIC src/sys/amd64/isa isa_dma.c src/sys/arm/arm busdma_machdep.c mem.c pmap.c src/sys/arm/
Hm, it could be a temporal paradox. Do you happen to live somewhere where it isn't 04:21:44 (the point in time when it was commited) yet? If yes then just wait till this time. After all information cannot travel faster than the speed of light, otherwise it would end up in the future. Alternatively this could be a joke by Kris, but I think a temporal paradox if far more likely. (-: Indeed. Well, I'm off to cradle my son. Let me know how it all turns out. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/cam/scsi scsi_sg.c scsi_sg.h src/sys/modules/cam Makefile src/sys/conf NOTES files src/sys/compat/linux linux_ioctl.c linux_ioctl.h
Cool- does this mean we should commit sg3_utils to ports then? On Sat, 7 Apr 2007, Scott Long wrote: scottl 2007-04-07 19:40:58 UTC FreeBSD src repository Modified files: sys/modules/cam Makefile sys/conf files NOTES sys/compat/linux linux_ioctl.c linux_ioctl.h Added files: sys/cam/scsi scsi_sg.c scsi_sg.h Log: Add the CAM 'SG' peripheral device. This device implements a subset of the Linux SCSI SG passthrough device API. The intention is to allow for both running of Linux apps that want to talk to /dev/sg* nodes, and to facilitate porting of apps from Linux to FreeBSD. As such, both native and linuxolator entry points and definitions are provided. Caveats: - This does not support the procfs and sysfs nodes that the Linux SG driver provides. Some Linux apps may rely on these for operation, others may only use them for informational purposes. - More ioctls need to be implemented. - Linux uses a naming scheme of "sg[a-z]" for devices, while FreeBSD uses a scheme of "sg[0-9]". Devfs aliasis (symlinks) are automatically created to link the two together. However, tools like camcontrol only see the native names. - Some operations were originally designed to return byte counts or other data directly as the syscall return value. The linuxolator doesn't appear to support this well, so this driver just punts for these cases. Now that the driver is in place, others are welcome to add missing functionality. Thanks to Roman Divacky for pushing this work along. Revision ChangesPath 1.1 +987 -0src/sys/cam/scsi/scsi_sg.c (new) 1.1 +139 -0src/sys/cam/scsi/scsi_sg.h (new) 1.138 +27 -0 src/sys/compat/linux/linux_ioctl.c 1.25 +34 -0 src/sys/compat/linux/linux_ioctl.h 1.1419+5 -0 src/sys/conf/NOTES 1.1191+1 -0 src/sys/conf/files 1.15 +1 -0 src/sys/modules/cam/Makefile ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/cam/scsi scsi_sg.c scsi_sg.h src/sys/modules/cam Makefile src/sys/conf NOTES files src/sys/compat/linux linux_ioctl.c linux_ioctl.h
Oh, agreed that it's unpleasant. Better than Solaris tho. By doing this you may have made FreeBSD a viable choice with respect to storagse. There are a lot of management tools for linux storage that use the sg interfaces. Bravo. To tell you the truth, the SG device has one of the worst programming interfaces that I've ever seen. Even the various official docs on it complain about how bad it is. I've written apps for CAM, including a swiss-army-knife java-based management app, and CAM is vastly superior. I tried porting the app to linux and gave up due to how limited and unpleasant it was. From the kernel side, it's even scarier. But beyond that, the work I committed here was about opening up FreeBSD to more storage management opportunities. So I'm happy with whatever anyone wants to do with it that furthers that goal. I'd like to see the native interface be used as a bridge to help introduce programmers to FreeBSD and CAM; if the sg3_utils package is a step in that direction or if it provides tools that camcontrol doesn't, then go for it. Scott [EMAIL PROTECTED] wrote: Cool- does this mean we should commit sg3_utils to ports then? On Sat, 7 Apr 2007, Scott Long wrote: scottl 2007-04-07 19:40:58 UTC FreeBSD src repository Modified files: sys/modules/cam Makefile sys/conf files NOTES sys/compat/linux linux_ioctl.c linux_ioctl.h Added files: sys/cam/scsi scsi_sg.c scsi_sg.h Log: Add the CAM 'SG' peripheral device. This device implements a subset of the Linux SCSI SG passthrough device API. The intention is to allow for both running of Linux apps that want to talk to /dev/sg* nodes, and to facilitate porting of apps from Linux to FreeBSD. As such, both native and linuxolator entry points and definitions are provided. Caveats: - This does not support the procfs and sysfs nodes that the Linux SG driver provides. Some Linux apps may rely on these for operation, others may only use them for informational purposes. - More ioctls need to be implemented. - Linux uses a naming scheme of "sg[a-z]" for devices, while FreeBSD uses a scheme of "sg[0-9]". Devfs aliasis (symlinks) are automatically created to link the two together. However, tools like camcontrol only see the native names. - Some operations were originally designed to return byte counts or other data directly as the syscall return value. The linuxolator doesn't appear to support this well, so this driver just punts for these cases. Now that the driver is in place, others are welcome to add missing functionality. Thanks to Roman Divacky for pushing this work along. Revision ChangesPath 1.1 +987 -0src/sys/cam/scsi/scsi_sg.c (new) 1.1 +139 -0src/sys/cam/scsi/scsi_sg.h (new) 1.138 +27 -0 src/sys/compat/linux/linux_ioctl.c 1.25 +34 -0 src/sys/compat/linux/linux_ioctl.h 1.1419+5 -0 src/sys/conf/NOTES 1.1191+1 -0 src/sys/conf/files 1.15 +1 -0 src/sys/modules/cam/Makefile ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/cam/scsi scsi_sg.c scsi_sg.h src/sys/modules/cam Makefile src/sys/conf NOTES files src/sys/compat/linux linux_ioctl.c linux_ioctl.h
I didn't have the time- Doug is kinda pissed at me because of that. On Mon, 9 Apr 2007, Scott Long wrote: I guess this work never got into ports? I'd like to see if there, even if it's augmented with other non-CAM versions. Scott Kenneth D. Merry wrote: That's a pretty neat trick! Thanks Scott! For what it's worth, Doug Gilbert already ported sg3_utils and sdparm to CAM a while back. I see a message from him to -scsi in March, 2006, announcing it. Ken On Sat, Apr 07, 2007 at 18:02:12 -0600, Scott Long wrote: To tell you the truth, the SG device has one of the worst programming interfaces that I've ever seen. Even the various official docs on it complain about how bad it is. I've written apps for CAM, including a swiss-army-knife java-based management app, and CAM is vastly superior. I tried porting the app to linux and gave up due to how limited and unpleasant it was. From the kernel side, it's even scarier. But beyond that, the work I committed here was about opening up FreeBSD to more storage management opportunities. So I'm happy with whatever anyone wants to do with it that furthers that goal. I'd like to see the native interface be used as a bridge to help introduce programmers to FreeBSD and CAM; if the sg3_utils package is a step in that direction or if it provides tools that camcontrol doesn't, then go for it. Scott [EMAIL PROTECTED] wrote: Cool- does this mean we should commit sg3_utils to ports then? On Sat, 7 Apr 2007, Scott Long wrote: scottl 2007-04-07 19:40:58 UTC FreeBSD src repository Modified files: sys/modules/cam Makefile sys/conf files NOTES sys/compat/linux linux_ioctl.c linux_ioctl.h Added files: sys/cam/scsi scsi_sg.c scsi_sg.h Log: Add the CAM 'SG' peripheral device. This device implements a subset of the Linux SCSI SG passthrough device API. The intention is to allow for both running of Linux apps that want to talk to /dev/sg* nodes, and to facilitate porting of apps from Linux to FreeBSD. As such, both native and linuxolator entry points and definitions are provided. Caveats: - This does not support the procfs and sysfs nodes that the Linux SG driver provides. Some Linux apps may rely on these for operation, others may only use them for informational purposes. - More ioctls need to be implemented. - Linux uses a naming scheme of "sg[a-z]" for devices, while FreeBSD uses a scheme of "sg[0-9]". Devfs aliasis (symlinks) are automatically created to link the two together. However, tools like camcontrol only see the native names. - Some operations were originally designed to return byte counts or other data directly as the syscall return value. The linuxolator doesn't appear to support this well, so this driver just punts for these cases. Now that the driver is in place, others are welcome to add missing functionality. Thanks to Roman Divacky for pushing this work along. Revision ChangesPath 1.1 +987 -0src/sys/cam/scsi/scsi_sg.c (new) 1.1 +139 -0src/sys/cam/scsi/scsi_sg.h (new) 1.138 +27 -0 src/sys/compat/linux/linux_ioctl.c 1.25 +34 -0 src/sys/compat/linux/linux_ioctl.h 1.1419+5 -0 src/sys/conf/NOTES 1.1191+1 -0 src/sys/conf/files 1.15 +1 -0 src/sys/modules/cam/Makefile ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/cam cam_ccb.h cam_periph.c cam_periph.h cam_sim.c cam_sim.h cam_xpt.c cam_xpt.h cam_xpt_periph.h src/sys/cam/scsi scsi_cd.c scsi_ch.c scsi_da.c scsi_low.c scsi_pass.c
I'm planning on writing a few pages of design docs on this in the next few days to give people a guide for locking down their drivers. That would be much appreciated. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netinet6 esp_camellia.c
On Wed, 9 May 2007, [EMAIL PROTECTED] wrote: At Wed, 9 May 2007 23:19:55 + (UTC), Matt Jacob wrote: mjacob 2007-05-09 23:19:55 UTC FreeBSD src repository Modified files: sys/netinet6 esp_camellia.c Log: Need sys/cdevs.h for the macro FBSDID to work. Thanks. Pointy hat to, George no worries ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/mpt mpt.c mpt.h mpt_cam.c mpt_cam.h mpt_pci.c mpt_raid.c
Matt Jacob wrote: mjacob 2007-05-05 20:18:25 UTC FreeBSD src repository Modified files: sys/dev/mpt mpt.c mpt.h mpt_cam.c mpt_cam.h mpt_pci.c mpt_raid.c Log: Make this driver MP safe and still be a multi-release driver. Obtained from: 99% of the work done by Scott Long. MFC after: 3 days Are there still plans to MFC this work? Regards, Richard Yes, but in no great hurry because, it won't affect RELENG_6 because RELENG_6 hasn't got the rest of the MP safe CAM stuff. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/hptmv ioctl.c
mjacob 2007-05-20 16:49:10 UTC FreeBSD src repository Modified files: sys/dev/hptmvioctl.c Log: Make gcc 4.2 happy by initiatlizing controller && channel prior to a call to a function which *might* then initialize them. MFC after: 3 days Isn't the bug that the function doesn't always initialize them? Bruce That was a meta-comment- I should have made it clearer. The function get_disk_location *will* always init them, but gcc-4.2 doesn't know that, and unlike previous versions of gcc, gcc-4.2 no longer will assume that a function that you pass a pointer to local data to will actually fill them in. -matt ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/hptmv ioctl.c
Sounds like more wonderful roadblocks from the GCC team. GCC is a great app, but it would be nice if it could be used as a tool for software development. It is a fine toolchain despite some of these issues. It does concern me greatly though that the majority of software development is now dependent on it. When was the last time anyone tried to build the entire FreeBSD source tree with a non-GNU compiler? ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/hptmv ioctl.c
On Mon, 21 May 2007, Bruce Evans wrote: On Sun, 20 May 2007 [EMAIL PROTECTED] wrote: mjacob 2007-05-20 16:49:10 UTC FreeBSD src repository Modified files: sys/dev/hptmvioctl.c Log: Make gcc 4.2 happy by initiatlizing controller && channel prior to a call to a function which *might* then initialize them. MFC after: 3 days Isn't the bug that the function doesn't always initialize them? That was a meta-comment- I should have made it clearer. The function get_disk_location *will* always init them, but gcc-4.2 doesn't know that, But the non-bug is still in the function and should be fixed and documented there, not in all callers. I can't parse this. and unlike previous versions of gcc, gcc-4.2 no longer will assume that a function that you pass a pointer to local data to will actually fill them in. No, gcc-4.2 isn't that broken. Initializing variables indirectly using init(&var1, &var1) is a C idiom and is used a lot, but gcc-4.2 only warns about a few such calls. A typical use is bzero(&var, sizeof(var)) to initialize a variable to all 0's. gcc-4.2 doesn't warn about this, and I think it wouldn't warn if you misspelled the size parameter so that the variable is only half initialized... I think gcc-4.2 only warns if it can look inside the function, and the function either doesn't initialize the variables or gcc cannot tell whether it does. In hptmv/ioctl.c, the problem is that the function searches a list and only initializes the variables if the list is non-empty. gcc cannot see if the list is non-empty, and neither can I. That's right. It at least depends upon the hptmv configuring for there to be a non-zero controller list and for it to be possible that the function will be called. I'm going to try something you indirectly suggested which is to add the initialization in the called function- that would be preferrable. [mention of style bugs deleted] Style cleanups come after syntactic issues. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/mpt mpt.c mpt.h mpt_cam.c
Awesome! Thanks1 On Sun, 3 Jun 2007, Scott Long wrote: scottl 2007-06-03 23:13:05 UTC FreeBSD src repository Modified files: sys/dev/mpt mpt.c mpt.h mpt_cam.c Log: mpt.c: mpt.h: Add support for reading extended configuration pages. mpt_cam.c: Do a top level topology scan on the SAS controller. If any SATA device are discovered in this scan, send a passthrough FIS to set the write cache. This is controllable through the following tunable at boot: hw.mpt.enable_sata_wc: -1 = Do not configure, use the controller default 0 = Disable the write cache 1 = Enable the write cache The default is -1. This tunable is just a hack and may be deprecated in the future. Turning on the write cache alleviates the write performance problems with SATA that many people have observed. It is not recommend for those who value data reliability! I cannot stress this strongly enough. However, it is useful in certain circumstances, and it brings the performence in line with what a generic SATA controller running under the FreeBSD ATA driver provides (and the ATA driver has had the WC enabled by default for years). Revision ChangesPath 1.42 +154 -29 src/sys/dev/mpt/mpt.c 1.41 +55 -3 src/sys/dev/mpt/mpt.h 1.57 +305 -0src/sys/dev/mpt/mpt_cam.c ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/mpt mpt_pci.c
Sorry- should have said "broader testing", which would include FC 4Gb cards. On Wednesday 15 November 2006 15:18, Matt Jacob wrote: mjacob 2006-11-15 20:18:09 UTC FreeBSD src repository Modified files: sys/dev/mpt mpt_pci.c Log: Turn off MSI until some testing is done. Revision ChangesPath 1.40 +2 -0 src/sys/dev/mpt/mpt_pci.c Works great here on the box I tested it on with both MSI and MSI-X, so it wasn't untested. -- John Baldwin ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/mpt mpt_pci.c
MSI/MSI-X seemed work with MPT for SAS, 4Gb FibreChannel on one system (SuperMicro Xeon) and 2Gb FibreChannel on another (4xdual core Opteron), but failed for onboard MPT on that system (dual core Opteron) mpt3: request 0x80e75050:96 timed out for ccb 0xff01433ec400 (req->ccb 0xff01433ec400) mpt3: completing timedout/aborted req 0x80e75050:96 mpt3: Timedout requests already complete. Interrupts may not be functioning. mpt2: request 0x80e67050:96 timed out for ccb 0xff0141c75c00 (req->ccb 0xff0141c75c00) mpt2: completing timedout/aborted req 0x80e67050:96 mpt2: Timedout requests already complete. Interrupts may not be functioning. MSI/MSI-X failed to work for the onboard em on the SuperMicro system. Given the (unselective) failure rate for me and the relatively small sample, but with two pretty widely used system types I'd like to suggest that you reconsider making the MSI and MSI-X being 'on' as the default. -matt Sorry- should have said "broader testing", which would include FC 4Gb cards. On Wednesday 15 November 2006 15:18, Matt Jacob wrote: mjacob 2006-11-15 20:18:09 UTC FreeBSD src repository Modified files: sys/dev/mpt mpt_pci.c Log: Turn off MSI until some testing is done. Revision ChangesPath 1.40 +2 -0 src/sys/dev/mpt/mpt_pci.c Works great here on the box I tested it on with both MSI and MSI-X, so it wasn't untested. -- John Baldwin ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/mpt mpt_pci.c
Could you please send the bootverbose output from these problem systems? Sure- I'll put the info up in http://people.freebsd.org/~mjacob shortly. Look- MSI is look a lot of other h/w features. It's been available in the h/w years before software has taken advantage of it, so the likelihood of older h/w just plain not working when s/w finally turns it on is pretty high. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/mpt mpt_pci.c
see http://people.freebsd.org/~mjacob for 2 bootverbose files. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/mpt mpt_pci.c
On Wed, 15 Nov 2006, Scott Long wrote: [EMAIL PROTECTED] wrote: see http://people.freebsd.org/~mjacob for 2 bootverbose files. Ah, it looks like the MPT chips support 8 messages. I think that John's patch assumes only 1 message for it. No, John's patch will only enable MSI for a count of one. The PCI cards I have that support MSI are: AMD: QLogic 6312 (MSI 8) LSI-Logic 1030 (MSI 1) LSI-Logic 1030 (MSI 1) [ STUPID ME- The FC929 doesn't have MSI ] Broadcom NetXtreme (MSI 8) Broadcom NetXtreme (MSI 8) SuperMicro LSI-Logic 4Gb (MSI-1 MSI-X 1) LSI-Logic 4Gb (MSI-1 MSI-X 1) LSI-Logic SAS (MSI-1 MSI-X 1) QLogic 2422 4Gb (MSI 8) QLogic 2422 4Gb (MSI 8) em (MSI 1) I would guess you were looking at the one of the other devs. For some devices, requesting 1 message when N are available will work, but it really is undefined behaviour and is dependent on the device to DTRT. So in your case, some of the MPT chips handled it well, some did not. Just out of curiosity, do you have any MPT docs that describe its MSI capabilities? In any case, it should probably be disabled in the MPT driver until we have a better understanding of how it works there. For your if_em problem, I'm not seeing what the problem is. It looks like em0 was successful at getting an IP address over DHCP, so I would assume that interrupts are working on it. Nope. That's why I included the change to disable msi in the boot verbose (there are two boot sessions there). You can have a *mostly* functional ethernet w/o interrupts functioning- you just get watchdog resets. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/mpt mpt_pci.c
Just to increase the population, I've included Dell 2850 (both i386 and amd64 instantiations) as a 'success' bootverbose logs with 5 distinct MPT devices each with MSI-1. -matt ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/bce if_bce.c src/sys/dev/em if_em.c if_em.h src/sys/dev/mpt mpt.h mpt_pci.c
Is there some convention for MSI naming? Or are the resources basically anonymous? They are just IRQ values. On x86 they will be >= 256, but that may not be true on other platforms. Other busses might also support multiple IRQs per device (if you had HT peripherals I think they could do this). In general IRQs are just cookies anyway. On x86 they index into the interrupt_sources[] array. On other platforms they can have other meanings. It would almost be better if SYS_RES_IRQ was just SYS_RES_INTR. Let me put back on my very very dusty Solaris DDI team hat and point out that you either coerce the naming of interrupts to an architected number space (as did Digital Unix and does Linux and more or less does FreeBSD) or leave the naming of interrupts to the bus nexus it has meaning to. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/boot/i386/btx/btx btx.S
And the crowd goes wild! Thanks! This will fix all those SunFire 4100s. On Wed, 6 Dec 2006, John Baldwin wrote: jhb 2006-12-06 17:45:35 UTC FreeBSD src repository Modified files: sys/boot/i386/btx/btx btx.S Log: Ignore any breakpoint instructions (int 3) we encounter in vm86 mode rather than treating them as a fatal exception and halting. At least one storage BIOS (some newer mpt(4) parts) have a breakpoint instruction in their disk read routine. MFC after: 3 days Revision ChangesPath 1.44 +2 -0 src/sys/boot/i386/btx/btx/btx.S ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/amd64/conf GENERIC
David E. O'Brien wrote: obrien 2006-12-14 03:57:34 UTC FreeBSD src repository Modified files:(Branch: RELENG_6) sys/amd64/conf GENERIC Log: Turn on SMP in the default kernel. Most FreeBSD/amd64 machines are either multi-socket and/or multi-core. RevisionChangesPath 1.439.2.16 +3 -0 src/sys/amd64/conf/GENERIC I guess you missed /sys/amd64/conf/SMP and all of the work that was done in sysinstall to detect and auto-install an SMP kernel. Idiot. Welcome back. First of all, no need to be so surly- I'm sure David meant well. Secondly, I would *like* to have SMP on as a default in RELENG_6 for amd64, as it would avoid doing what I've done twice already- fresh sysinstall may or may not have installed an SMP kernel but going off and building GENERIC then lost me my SMP. It's sort a violation of POLA. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/amd64/conf GENERIC
There wasn't a full switchover to SMP at 6.0 because an SMP kernel on a UP system incurs a measurable runtime overhead, and we wanted to present a system that showed the best of FreeBSD to people who wanted to run it But David's point is that most AMD64 boxes *are* SMP, not UP. Is that wrong? ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/amd64/conf GENERIC
3. This change, had it not been reverted, would have broken the consistency in the major release stream that we were trying to achieve. You spell it 'POLA', I spell it 'consistent'. Either way, I think that we both have a deep concern and appreciation for doing the right thing and not pissing people off with surprises. Amen to that. That's a very good point. Thanks. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/amd64/conf GENERIC
I respect Matt's questions on the topic, and I hope that I am providing reasonable answers and conversation on it. Yes. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/aac aac_pci.c src/sys/dev/advansys adv_eisa.c adv_isa.c adv_pci.c advansys.c adw_pci.c adwcam.c src/sys/dev/aha aha.c aha_isa.c aha_mca.c src/sys/dev/ahb ahb.c src/sys/dev/
BTW, maxim, how about ciss(4)? http://www.freebsd.org/cgi/query-pr.cgi?pr=105989 Whoops - missed that one. I'll catch it. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/netgraph ng_ppp.c
/usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c: In function `ng_ppp_rcvdata': /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:1287: warning: comparison is always true due to limited range of data type *** Error code 1 I commented out the KASSERT in order to get the kernel buildable again. Would you be able to take a look at the logic in the KASSERT? I'd rather not guess what you'd like there and possibly get it wrong. thanks, Fools rush in (me). I changed the logic. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/cam/scsi scsi_da.c
*/
- {T_DIRECT, SIP_MEDIA_REMOVABLE, "*", "MP3 Player*",
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, "EM732X", "MP3 Player*",
"1.0"}, /*quirks*/ DA_Q_NO_SYNC_CACHE
},
};
Thanks.
a) It'd be nice if we could move quirks to some sysctl or hints format
to get out of this tail chasing business.
b) We should have a 'scsi_pessimistic' flag that would be used for
install kernels and as emergency parachutes for people that allows
people to drive h/w with minimum requirements and functionality.
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/cam/scsi scsi_da.c
a) It'd be nice if we could move quirks to some sysctl or hints format to get out of this tail chasing business. There are other databases besides quirks that'd be good to make more flexible. Wonder if splitting them into modules would be an improvement? Not as good as a sysctl or a hint but it would allow changing a GENERIC kernel w/o rebuilding. If people can't set it via the OK prompt, that's a problem. If you just do a module, all you're doing is moving compiled code from one place to another. IMO. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/cam/scsi scsi_da.c
If you just do a module, all you're doing is moving compiled code from one place to another. IMO. My thought was if it's split into a module then you can have alternative modules available at the loader prompt/menu to fallback to. Also if it's split out we can probably auto-generate it. umm, yes. So, what's wrong with an ascii sysctl/hint definition? ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/cam/scsi scsi_da.c
Nothing. I just thought I was suggesting something in-between what we have now and a pure ascii mechanism like hints that requires in-kernel parsing. You are. With mucho respect I would have to say that it doesn't interest me all that much. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/amd64/conf GENERIC src/sys/i386/conf GENERIC src/sys/ia64/conf GENERIC src/sys/pc98/conf GENERIC src/sys/powerpc/conf GENERIC src/sys/sparc64/conf GENERIC src/sys/sun4v/conf GE
I prefer that last option. Uniquify them somehow, and perhaps spit a warning out to console. "LABEL: ufs/ on device ad4s1b renamed to ufs/1". Maybe just force it to auto-increment that last number until it finds an available slot. If it can't find an available slot, then spit out an error about ambiguous GEOM labels This is exactly what I did for the g_multipath stuff. There is *some* notion of UUID in most of the GEOM label types- I did it as a more explicit real UUID, but the crux of the biscuit is what is the real unique id? Ascii names are useful, but they aren't usually veru unique. How many "oracle" labels will people pick? The choice I made is that the UUID is the *real* id. The ascii name is a 'convenience' name. If in a multipath or shared SAN environment, there is an ascii name collision during the taste operation, you can and do still build the geom but have to frob the name. Any kind of frob is okay because any automount using the ascii name is now going to fail. An alternative is to export the UUID as a name, which is probably the right thing to do also. This, btw, has come up for years (since RedHat 9) in Linux. The installer will pick "/boot" and "/" as the LABEL= qualifiers, which is a complete lose in a SAN or even in a multiboot non-shared environment, so I invariably change the LABEL= to UUID= qualifiers in both grub.conf and /etc/fstab. -matt ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/etc/mtree BSD.include.dist src/sbin/geom/class Makefile src/sbin/geom/class/multipath Makefile geom_multipath.c src/sys/conf NOTES files src/sys/geom/multipath g_multipath.c g_mult
thx (blush) but I'm sure that there are lots of flaws and bugs to find.
However, it is a start.
On Mon, 26 Feb 2007, Eric Anderson wrote:
On 02/26/07 22:01, Matt Jacob wrote:
mjacob 2007-02-27 04:01:58 UTC
FreeBSD src repository
Modified files:
etc/mtreeBSD.include.dist sbin/geom/class Makefile
sys/conf NOTES files sys/modules/geom Makefile Added
files:
sbin/geom/class/multipath Makefile geom_multipath.c
sys/geom/multipath g_multipath.c g_multipath.h
sys/modules/geom/geom_multipath Makefile Log:
First cut at GEOM based multipath. This is an active/passive{/passive...}
arrangement that has no intrinsic internal knowledge of whether devices
it is given are truly multipath devices. As such, this is a simplistic
approach, but still a useful one.
And the crowd goes wild!
Great work!
Thanks!
Eric
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/amd64/conf GENERIC src/sys/i386/conf GENERIC src/sys/ia64/conf GENERIC src/sys/pc98/conf GENERIC src/sys/powerpc/conf GENERIC src/sys/sparc64/conf GENERIC src/sys/sun4v/conf GE
I'm inclined to agree with Dag-Erling here. Originally I was pretty happy that this got turned on automatically, but on the whole I think the points made are good ones. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/share/man/man4 isp.4
Do you know or did you ever test if QLE246x is supported ? I believe that this is just a marketing name difference from the 2422, but to be sure you can loan me one for a week. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/mpt mpt.h mpt_cam.c
On Sun, Mar 11, 2007 at 01:55:00AM +, Matt Jacob wrote: Log: feedback from RELENG_5 port Um, yes, but what is the change? Point made. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
