Joseph Olatt wrote:
[EMAIL PROTECTED]:0:14:0: class=0x010485 card=0x01371025 chip=0x07f810de
rev=0xa2 hdr=0x00
vendor = 'Nvidia Corp'
class = mass storage
subclass = RAID
Do you still have this problem?
It seems that your controller is AHCI-capable.
I can make a patch
Hi,
That seems to be working. I've been up and running for 2 hours now with
your patch.
The machine is a bit slow but I have both WITNESS and INVARIANTS
enabled to make sure everything is fine.
Rergads,
Mario
Robert Watson wrote:
On Sun, 21 Sep 2008, Mario Sergi
On Wed, Sep 10, 2008 at 10:54 PM, Carlos A. M. dos Santos
<[EMAIL PROTECTED]> wrote:
> On Wed, Sep 10, 2008 at 5:34 PM, Jeff Blank <[EMAIL PROTECTED]> wrote:
>> I just upgraded a RELENG_7 (amd64) box from 20080714 to "latest"
>> (which seems to be from a few days ago--no changes from Monday
>> morn
On Sep 22, 2008, at 3:46 PM, Robert Watson wrote:
The key point here holds, however: I think we should not ever be in
the position of telling people that support lifetime on a release
has been reduced.
I agree. However, there are other ways of doing this than to create
overlapping window
On Sep 22, 2008, at 2:56 PM, Doug Barton wrote:
I'd also like to point out that there is another chicken-egg problem
that has been glossed over in this thread. You have said many times
that
it's hard for a company to devote resources to testing a given release
candidate without knowing in adva
On Sep 22, 2008, at 1:54 PM, Robert Watson wrote:
This is precisely what we already do -- we guarantee we will
support the last release on a branch for 24 months after the
release. The point of concern being discussed is that we can't
tell you for sure which minor release will be the last r
On Sep 22, 2008, at 1:32 PM, Robert Watson wrote:
Long answer: we're under-manned for our current commitments, and
have seen longer advisory cycles than we would like. My guess is
that we could eat the first 25% of a person just catching up on
current obligations so as to reduce latency on
On Sep 22, 2008, at 1:08 PM, Robert Watson wrote:
I'm not sure I agree with this analysis
...
Counting on my fingers, that's 7 FreeBSD-specific, 4 that lie in
code we basically maintain, and 8 that are in externally maintained
software. Seems like a pretty even split.
Acknowledged
On Mon, Sep 22, 2008 at 5:37 PM, Doug Barton <[EMAIL PROTECTED]> wrote:
> Dylan Cochran wrote:
>> One of the biggest (and most prominent, though not obviously so)
>> issues is the lack of concurrency with regards to releases. With the
>> default system, having multiple freebsd releases side by side
On Mon, 22 Sep 2008, Robert Watson wrote:
I think you are using "last release" in a different way. "the last
release" is always the most release release. Right now 6.3 will have
support for longer than 6.4 will, which is the nature of the problem I
raised. If you always supported the most
I updated /usr/src with cvsup and recompiled the kernel
This error still continue. :(
System is 7.0-RELEASE.
> Date: Sun, 21 Sep 2008 17:13:16 -0700> From: [EMAIL PROTECTED]> To: [EMAIL
> PROTECTED]> CC: [EMAIL PROTECTED]; freebsd-stable@freebsd.org; [EMAIL
> PROTECTED]> Subject:
Dylan Cochran wrote:
> One of the biggest (and most prominent, though not obviously so)
> issues is the lack of concurrency with regards to releases. With the
> default system, having multiple freebsd releases side by side (both
> different versions, and different architectures) is infeasible. This
Jo Rhett wrote:
> On Sep 19, 2008, at 9:41 PM, Gary Palmer wrote:
>> Or to put it another way, what to you is "support" in terms of
>> FreeBSD releases. As far as I am aware, if you stick on a
>> RELENG_X_Y_Z_RELEASE tag
>> then the most you get is security fixes. No new features,
>> no new driver
On Mon, 22 Sep 2008, Jo Rhett wrote:
On Sep 21, 2008, at 1:57 AM, Robert Watson wrote:
This is precisely what we already do -- we guarantee we will support the
last release on a branch for 24 months after the release. The point of
concern being discussed is that we can't tell you for sure wh
On Mon, 22 Sep 2008, Jo Rhett wrote:
On Sep 22, 2008, at 12:41 PM, Robert Watson wrote:
Lack of human resources, to use a vile term, is currently the limiting
factor. What happens when that is cleared is another question, but in the
end there aren't a whole lot of paths to greater efficiency
On Mon, 22 Sep 2008, Jo Rhett wrote:
I assumed not. I was curious to what extent outside people could help
support the process, while leaving commits to the internal people. For
example, for everything except the jail vulnerability in the last 4 years
the security problems were related to t
On Sep 22, 2008, at 12:41 PM, Robert Watson wrote:
Lack of human resources, to use a vile term, is currently the
limiting factor. What happens when that is cleared is another
question, but in the end there aren't a whole lot of paths to
greater efficiency here:
...
This is an inherently man
On Sep 21, 2008, at 1:57 AM, Robert Watson wrote:
This is precisely what we already do -- we guarantee we will support
the last release on a branch for 24 months after the release. The
point of concern being discussed is that we can't tell you for sure
which minor release will be the last r
Thank you for answering the resources problem in detail, I appreciate
it.
For what secteam support of the base system costs, it's mainly time
for the members of the security team which is the cost. The more
branches, the more time is required. This is not a linear cost and
has multiple parts
On Mon, 22 Sep 2008, Jo Rhett wrote:
Again, what you are saying makes a lot of sense, and I have no problem with
it. We're just missing the crucial bit -- what is it going to take to reach
that goal? Regardless of commit bits, etc and such forth. Is 10 hours a
week of one person enough? Doe
On Sep 20, 2008, at 1:56 PM, Simon L. Nielsen wrote:
2 years for each supported branch would be excellent, although I'm
open to alternatives. Right now 6.4 will EoL before 6.3 will :-(
Eh, where did you get that information? AFAIK the EoL date of 6.4 has
not yet been decided (and I should kn
On Sep 20, 2008, at 12:04 PM, Gary Palmer wrote:
Actually Robert, to be fair to Jo, I suspect it is more proper to say
"$COMPANY wants extended support lifetimes. What can I, or $COMPANY,
do to help make that happen?". I think its been misinterpreted as
Jo saying "Let me do the work". He has o
On Sep 20, 2008, at 3:37 AM, Robert Watson wrote:
The tension here is between making promises we can definitely keep
and starting to make promises that we can't. We'd like to err on
the former, rather than latter, side.
Yes. This is well understood and I agree with those priorities.
You a
On September 19, 2008 09:41 pm Gary Palmer wrote:
> On Fri, Sep 19, 2008 at 07:38:32PM -0700, Jo Rhett wrote:
> > Without input from the current release team extending the support
> > schedule is not possible.
>
> Inquiry - is release team the constraint?
>
> Or to put it another way, what to you
On Thu, 2008-09-04 at 18:48 +0100, Gavin Atkinson wrote:
> On Thu, 2008-09-04 at 11:32 -0600, Dan Allen wrote:
> > On 4 Sep 2008, at 10:29 AM, Gavin Atkinson wrote:
> >
> > > This is supported by the iwn(4) driver in CURRENT, and it should be
> > > quite easy to port the driver to 7-STABLE. If yo
On 9/22/08, Jason C. Wells <[EMAIL PROTECTED]> wrote:
> Jason C. Wells wrote:
>> Jeremy Chadwick wrote:
>>> On Sun, Sep 21, 2008 at 11:17:58AM -0700, Jason C. Wells wrote:
I have the problem similar to one described in 20071024 UPDATING.
The build is running inside a jail. The system is
Hi,
I have an Asus P5BV-C/4L mainboard with two onboard SATA controllers.
One of them, the Marvell 88SX6145, isn't support by FreeBSD 7.
It seems to be detected as an ata controller:
atapci0: port
0xec00-0xec07,0xe880-0xe883,0xe800-0xe807,0xe480-0xe483,0xe400-0xe40f
mem 0xfbfffc00-0xfbff irq
Attached is an MFC candidate for a patch I just merged to 8.x, which corrects
the UDP lock recursion issue both of you were running into. If it settles
well for a couple of days in HEAD then I'll go ahead and request an MFC from
re@, but your confirmation as to whether or not this corrects th
28 matches
Mail list logo
