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
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
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
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
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
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
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
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
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]
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
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
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
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
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
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
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
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
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
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!
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
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
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
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)
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
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.
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,
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
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
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
*/
- {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
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
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,
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.
___
/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
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
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
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
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.
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
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
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
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
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
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]
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
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
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:
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]
| 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
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
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
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
'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]
53 matches
Mail list logo
