Re: MFC of em/igb drivers

[Ganbold]

Jack Vogel wrote:

I got the new drivers in Friday afternoon for those that don't see CVS
messages.

The igb driver is for 82575 and 82576 adapters, it has multiqueue support and
MSIX, there will be more server type enhancements in that driver as I get the
time.

The em driver now will be client oriented, the latest hardware support however
is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter,
that actually also has MSIX. This first released support for it will
use 3 interrupt
vectors, one for TX, one for RX, and Link. The hardware actually supports 5
vectors, so I am planning to add support for another RX and TX queue as my
schedule allows.

Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver
provides init and an ioctl interface to use that facility, I hope we
see software
support follow on soon. This is an early announcement, I am not sure on
exact dates for availability but they should be soon.

As ever, issues and bugs should be sent to me. Cheers everyone!

Jack
  


Jack,

I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following:
...
[EMAIL PROTECTED]:0:25:0:class=0x02 card=0x2800103c chip=0x104a8086 
rev=0x02 hdr=0x00

   vendor = 'Intel Corporation'
   device = '82566DM Gigabit Network Connection'
   class  = network
   subclass   = ethernet
...
# uname -an
FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun  5 
11:12:34 ULAT 2008 
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/FIREWALL  i386



It has some problem, 1000baseTX connection status almost never goes to 
active in bridged mode, sometimes
it goes to active but then immediately it goes to no carrier. (The other 
end is Cisco4507R, Gigabit Ethernet port)

...
em0: flags=8943 metric 0 
mtu 1500

   options=198
   ether 00:0f:fe:82:23:db
   media: Ethernet 1000baseTX  (autoselect)
   status: no carrier
...

Any idea how to solve this issue?

thanks,

Ganbold



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"



  



--
Q: How many pre-med's does it take to change a lightbulb? A: Five: One 
to change the bulb and four to pull the ladder out from under him.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: MFC of em/igb drivers

[Jeremy Chadwick]

On Fri, Jun 06, 2008 at 03:49:40PM +0800, Ganbold wrote:
> Jack Vogel wrote:
>> I got the new drivers in Friday afternoon for those that don't see CVS
>> messages.
>>
>> The igb driver is for 82575 and 82576 adapters, it has multiqueue support and
>> MSIX, there will be more server type enhancements in that driver as I get the
>> time.
>>
>> The em driver now will be client oriented, the latest hardware support 
>> however
>> is for 82574, Hartwell, which is a really nice low cost PCIE dual-port 
>> adapter,
>> that actually also has MSIX. This first released support for it will
>> use 3 interrupt
>> vectors, one for TX, one for RX, and Link. The hardware actually supports 5
>> vectors, so I am planning to add support for another RX and TX queue as my
>> schedule allows.
>>
>> Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver
>> provides init and an ioctl interface to use that facility, I hope we
>> see software
>> support follow on soon. This is an early announcement, I am not sure on
>> exact dates for availability but they should be soon.
>>
>> As ever, issues and bugs should be sent to me. Cheers everyone!
>
> I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following:
> ...
> [EMAIL PROTECTED]:0:25:0:class=0x02 card=0x2800103c 
> chip=0x104a8086 
> rev=0x02 hdr=0x00
>vendor = 'Intel Corporation'
>device = '82566DM Gigabit Network Connection'
>class  = network
>subclass   = ethernet
> ...
> # uname -an
> FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun  5 
> 11:12:34 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FIREWALL  
> i386
>
>
> It has some problem, 1000baseTX connection status almost never goes to 
> active in bridged mode, sometimes
> it goes to active but then immediately it goes to no carrier. (The other 
> end is Cisco4507R, Gigabit Ethernet port)
> ...
> em0: flags=8943 metric 0 
> mtu 1500
>options=198
>ether 00:0f:fe:82:23:db
>media: Ethernet 1000baseTX  (autoselect)
>status: no carrier
> ...
>
> Any idea how to solve this issue?

Have you tried disabling speed and duplex negotiation and explicitly
stating speed and duplex like so?

ifconfig_em0="... media 1000baseTX mediaopt full-duplex"

Cisco switches have a notorious history of not being "friendly" with
non-Cisco hardware.  Forcing duplex on both ends of the link (that means
on both the host side, and the Cisco side!) usually fixes it.

-- 
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: MFC of em/igb drivers

[Ganbold]

Jeremy Chadwick wrote:

On Fri, Jun 06, 2008 at 03:49:40PM +0800, Ganbold wrote:
  

Jack Vogel wrote:


I got the new drivers in Friday afternoon for those that don't see CVS
messages.

The igb driver is for 82575 and 82576 adapters, it has multiqueue support and
MSIX, there will be more server type enhancements in that driver as I get the
time.

The em driver now will be client oriented, the latest hardware support however
is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter,
that actually also has MSIX. This first released support for it will
use 3 interrupt
vectors, one for TX, one for RX, and Link. The hardware actually supports 5
vectors, so I am planning to add support for another RX and TX queue as my
schedule allows.

Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver
provides init and an ioctl interface to use that facility, I hope we
see software
support follow on soon. This is an early announcement, I am not sure on
exact dates for availability but they should be soon.

As ever, issues and bugs should be sent to me. Cheers everyone!
  

I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following:
...
[EMAIL PROTECTED]:0:25:0:class=0x02 card=0x2800103c chip=0x104a8086 
rev=0x02 hdr=0x00

   vendor = 'Intel Corporation'
   device = '82566DM Gigabit Network Connection'
   class  = network
   subclass   = ethernet
...
# uname -an
FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun  5 
11:12:34 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FIREWALL  
i386



It has some problem, 1000baseTX connection status almost never goes to 
active in bridged mode, sometimes
it goes to active but then immediately it goes to no carrier. (The other 
end is Cisco4507R, Gigabit Ethernet port)

...
em0: flags=8943 metric 0 
mtu 1500

   options=198
   ether 00:0f:fe:82:23:db
   media: Ethernet 1000baseTX  (autoselect)
   status: no carrier
...

Any idea how to solve this issue?



Have you tried disabling speed and duplex negotiation and explicitly
stating speed and duplex like so?

ifconfig_em0="... media 1000baseTX mediaopt full-duplex"
  


I tried it and it doesn't work.


Cisco switches have a notorious history of not being "friendly" with
non-Cisco hardware.  Forcing duplex on both ends of the link (that means
on both the host side, and the Cisco side!) usually fixes it.
  


Tried too, doesn't work.

Ganbold

--
Life is too important to take seriously. -- Corky Siegel
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

[Manfred Usselmann]

Hi,

On Thu, 05 Jun 2008 13:31:44 -0500
Paul Schmehl <[EMAIL PROTECTED]> wrote:

> --On Thursday, June 05, 2008 17:53:01 +0100 Tom Evans 
> <[EMAIL PROTECTED]> wrote:
> >
> > I think that, especially with open source products, there is a large
> > emphasis on testing in your own environments, and choosing the
> > 'correct' version of a particular software package is important.
> > For example, at $JOB, we had a lot of servers running 6.1 as it was
> > an extended lifetime release, so no point jumping to 6.2, instead
> > we waited for 6.3 to pass our integration testing.
> >
> 
> Not everyone has those kinds of resources.  The domain I'm referring
> to is a hobby site, run by a husband and wife.  They started with
> shared hosting and moved to a dedicated box when I volunteered to
> help with the backend work.  For several years we ran one server
> hosting dns, imaps, smtps, mail lists and websites.
> 
> Yes, it's not ideal, but when you have zero income you do what you
> can. Testing like you describe is out of the question.
> 
> We now have the embarrassment of riches of two servers; one for web
> and the old one for the rest.  The old box is still running 5.4
> SECURITY.  The new box is running 6.1.  I'd *like* to upgrade both
> boxes, and the older box can go offline comfortably for several hours
> without anyone but me noticing.  But if the web box goes down for 30
> seconds, queries from the users start pouring in.

What you are saying sounds like a contradiction to me. On one side it
is just a hobby site and generates no income and on the other hand it
is a critical server with millions of hits and the box can't even go
down for a short time.

What happens in case lets say your harddisk crashes? Something which is
not an exactly rare case...

If the users are not paying for the service they should be able to
accept a downtime, may it be scheduled or even completely unexpected.
Or pay / donate for a more reliable service (Redundant server as hot
standby / testbed etc.). 

Manfred

-- 
Manfred Usselmann <[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: Instant reboot with FreeBSD 6.3 and > 2GB RAM

[Volker Theile]

Hello,

i can confirm that the bug fix submitted with PR 108215 solves the reboot 
problem when using mfsroot images in FreeBSD 6.3. I will test it also on 
FreeBSD 7.0, but i assume that it will fix it there too.
Many users using FreeNAS reporting this reboot problem on their machines with 
RAM > 2GB.

Regards
Volker

 Original-Nachricht 
> Datum: Wed, 21 May 2008 21:08:25 +0200
> Von: Volker <[EMAIL PROTECTED]>
> An: [EMAIL PROTECTED]
> CC: freebsd-stable@freebsd.org, [EMAIL PROTECTED]
> Betreff: Re: Instant reboot with FreeBSD 6.3 and > 2GB RAM

> On 12/23/-58 20:59, [EMAIL PROTECTED] wrote:
> > Hello,
> > 
> > some users of FreeNAS which is based on FreeBSD 6.3 reported instant
> reboots on systems with > 2GB RAM (most of them use 4GB). The reboot occurs
> right after displaying the FreeBSD loader menu. Most of them told me that
> they can boot if they reduce RAM to <= 2GB.
> > 
> > We are using the following kernel configuration which is based on
> GENERIC:
> >
> http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-config/FREENAS-i386?revision=3291&view=markup
> > 
> > I found out another problem that causes a reboot on my 2GB machine. We
> are using a image for the LiveCD which is 64MB great. If i change back
> mfs_root size to 63MB all works well, but all above 64MB causes a reboot.
> > Is there any limitation?
> > 
> > Could someone help me out of this problem?
> > 
> > Regards
> > Volker
> 
> Hi Volker ;)
> 
> I'm not quite sure about your 2nd problem and your report is not quite
> detailed but from your description it looks like loader is causing that.
> As there's no filesystem available at that time, the loader has to read
> itself through the filesystem structures.
> 
> Knowing that, PR misc/108215 comes to mind. I've not been able to check
> if the issue and the patch to it is right but you may give it a try.
> Probably somebody with loader and filesystem (ufs) knowledge may answer
> that question quickly if the patch contained in the PR is right.
> 
> The report is about 6.2-R but at least I've checked loader code and 7.x
> code is the same. I came across that report yesterday and was unable to
> check the calculation.
> 
> If that is really the case, your problem may be related to that.
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=108215
> 
> Assuming the problem report is right, it's about reading huge files by
> loader reads in wrong sectors.
> 
> HTH
> 
> Volker

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: MFC of em/igb drivers

[Jeremy Chadwick]

On Fri, Jun 06, 2008 at 05:29:46PM +0800, Ganbold wrote:
>> Have you tried disabling speed and duplex negotiation and explicitly
>> stating speed and duplex like so?
>>
>> ifconfig_em0="... media 1000baseTX mediaopt full-duplex"
>>   
>
> I tried it and it doesn't work.
>
>> Cisco switches have a notorious history of not being "friendly" with
>> non-Cisco hardware.  Forcing duplex on both ends of the link (that means
>> on both the host side, and the Cisco side!) usually fixes it.
>>   
>
> Tried too, doesn't work.

Good to know.  Sounds like a driver problem; back to Jack for that one.
:-)

-- 
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

[Dag-Erling Smørgrav]

Paul Schmehl <[EMAIL PROTECTED]> writes:
> [...] I reacted in anger because I felt the OP was being savagely
> attacked rather than being responded to with professionalism.  Later
> in the thread some folks got around to asking which PRs he was
> referring to, but that was after attacking him for having the temerity
> to suggest that perhaps 6.2 shouldn't be EOL.  [...]  I don't recall
> him ever refusing.  I think after his initial post he's been forced to
> defend himself from attack from 360 degrees.  [...]

I came in late, and thus had the benefit of reading most of thread in
context rather than piece by piece over time, and in my opinion, the
above is a gross misrepresentation.  I think you need to go back and
re-read the thread from the beginning.  Here, let me help you.

Three people replied to Jo Rhett's initial email.  Here's what they
said, with Jo's own text elided:

Doug Barton:

> It isn't that we want people to upgrade, it's that we are trying to be
> realistic regarding what we have the resources to support.
> [...]
> I admit to not having been following 6.x too closely, but are these
> things that have been reported, or problems you're having personally?
> [...]
> Having an upgrade path is something every operation needs. "Set it and
> forget it" isn't a viable strategy in the current culture where 0-day
> vulnerabilities are becoming increasingly common.

Scott Long:

> Can you describe the bugs that are affecting you?
> [...]
> The expectation is always that newer versions of a stable branch will
> have few regressions, and thus upgrading is a low risk.

John Baldwin:

> FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 patches for 
> known deadlocks and kernel panics that were errata candidates for 6.2 that 
> never made it into RELENG_6_2 but all of them are in 6.3).  We also have many 
> machines with bge(4) and from our perspective 6.3 has less issues with bge0 
> devices than 6.2.
> 
> Given the real world experience I have, your claims of instability w/o even 
> testing 6.3 border on silly.  Also, when it comes to bge(4), you need to be 
> _very_ specific about what chipsets you are using and comparing those with 
> the chipsets in the bug reports you read.  The bge(4) driver in particular 
> covers a vast range of different hardware variations and is a bit of a 
> hodge-podge itself.  If there is a problem with a 5705 card then it may be 
> specific to just 5705 parts and not affect 575x, etc. parts.
> 
> Again, with 3ware, there are two different drivers (twe(4) vs twa(4)) and 
> again, you need to be more specific with which driver you are using and which 
> model controllers you have.

It takes a very active imagination to describe this as an "attack from
360 degrees".

The fun starts with the following exchange between Jo and Kris Kennaway
(who responded to Doug):

Kris Kennaway:

> Also, it's not like anyone should have been caught by surprise by
> the 6.2 EoL; the expiry date has been advertised since the 6.2
> release itself.

Jo Rhett:

> It has changed multiple times.  I keep reviewing and finding 6.3 bugs
> outstanding, and then observe the EoL get pushed.
>
> I'm surprised that it failed to get pushed this time.

This is competely untrue - but Kris doesn't swallow the bait, and relies
patiently and politely:

> I'm sorry that the FreeBSD project failed to conform to your
> expectations.  However, I invite you to actually try 6.3 for yourself
> instead of assuming that it will fail.

This is the crux of the matter - Jo is complaining about software he
hasn't even tried.  There is absolutely no way anybody can help him
until he actually tries 6.3 and reports any actual bugs and regressions
he finds.

This subthread quickly degrades after Chris Marlatt inists that we
should support LTS releases for four years instead of two, and takes
personal offense at the fact that we don't have the resources to do so.

Let's jump back to Scott Long's subthread:

Scott Long:

> Can you describe the bugs that are affecting you?

Jo Rhett:

> gmirror failures, 3ware raid driver timeouts, bge0 problems.  All
> three in production use on dozens of systems.

That is also untrue.  None of these are "bugs that are affecting [Jo]",
since he hasn't tried running 6.3 at all.

Scott Long:

> Give me specific details on the 3ware and bge problems.

Jo Rhett:

> Familiar with searching the open bug reports?  That's where I found
> them.
> 
> Sorry, I'm knee-deep in a major project that I've been working 16+
> hours a day on right now, and I just don't have the time for spurious
> queries.  Query the open bug reports for 6.3 and then explain to me
> again why 6.2 is no longer supported.

Scott asks him to describe the problems he's having, and he calls that
"spurious queries" which he doesn't have time for.  Is that Scott
attacking and disrespecting Jo, or Jo attacking and disrespecting Scott?
No wonder Scott gets annoyed:

> Really, if it's such a big issue that you have time to bitch

Re: gmirror patches

[Pete French]

> Patch is gzipped and can be easily gunziped after download. (and 
> uuencoded in webpage view)

Ah, yes, sorry about that - thought it would be obvious. I always
submit changes that way as I find that whitespace has a habit
of breaking otherwise.

> It is true that patch is better in plaintext diff.

How would I set about doing that without the whitespace being messed up
by email transit ? I have always found in the past that tabs end up as
spaces and then patch gets upset hwne you try to apply it.

-pete.

PS: thanks for the emai address BTW!
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: gmirror patches

[Miroslav Lachman]

Pete French wrote:

[...]


It is true that patch is better in plaintext diff.



How would I set about doing that without the whitespace being messed up
by email transit ? I have always found in the past that tabs end up as
spaces and then patch gets upset hwne you try to apply it.


I sent PR throught webform with plain text patch with txt extension 
(http://www.freebsd.org/cgi/query-pr.cgi?pr=124248), patch is shown on 
webpage with spaces instead of tabs, but if you download it, tabs are tabs.


Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

[Vivek Khera]

On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote:


 Speaking just for myself, I'd love to get a general response from
people who have run servers on both as to whether 6.3 is on average
more stable than 6.2.  I really haven't gotten any clear impression as


I'll throw in my "+1" for running 6.3.  I have it on many boxes, some  
of which run gmirror and some of which have bge devices (some with  
both).  Never any problems.  They operate things varying from Postgres  
servers to DNS servers to mail servers (postfix) under pretty  
consistent load pushing lots and lots of data both network and to disk.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

[Vivek Khera]

On Jun 4, 2008, at 8:22 PM, Jo Rhett wrote:

If you're asking why I don't turn a production environment over to  
being a freebsd-unstable-testbed, I can't really answer that  
question in a way you'd understand (if you were asking that question)


If you don't have an identical setup to test new software, then you're  
pretty much not able to ever upgrade anything, IMO, and your  
"production" environment *is* a testbed for new software.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

[Vivek Khera]

On Jun 4, 2008, at 9:03 PM, Adrian Chadd wrote:


If this is so important to you - contribute to the project and/or hire
a FreeBSD developer.


I've got a strange problem with jails and I've been trying to hire a  
freebsd developer, but I can't seem to get anyone to a) call me back.   
I got one response on "try doing xxx" which involved kernel hacking  
and such, which is beyond what I am in a position to do.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

[Clifton Royston]

On Fri, Jun 06, 2008 at 12:08:54PM -0400, Vivek Khera wrote:
> 
> On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote:
> 
> > Speaking just for myself, I'd love to get a general response from
> >people who have run servers on both as to whether 6.3 is on average
> >more stable than 6.2.  I really haven't gotten any clear impression as
> 
> I'll throw in my "+1" for running 6.3.  I have it on many boxes, some  
> of which run gmirror and some of which have bge devices (some with  
> both).  Never any problems.  They operate things varying from Postgres  
> servers to DNS servers to mail servers (postfix) under pretty  
> consistent load pushing lots and lots of data both network and to disk.

Thanks.  That sounds like the kind of broad experience I need,
particularly as the main group of servers are mail servers (spam
filtering machines running Postfix, with some config files on NFS.)

  -- Clifton

-- 
Clifton Royston  --  [EMAIL PROTECTED] / [EMAIL PROTECTED]
   President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

[Michael Gratton]

On Fri, 2008-06-06 at 12:08 -0400, Vivek Khera wrote:
> On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote:
> 
> >  Speaking just for myself, I'd love to get a general response from
> > people who have run servers on both as to whether 6.3 is on average
> > more stable than 6.2.  I really haven't gotten any clear impression as
> 
> I'll throw in my "+1" for running 6.3.  I have it on many boxes, some  
> of which run gmirror and some of which have bge devices (some with  
> both).  Never any problems.  They operate things varying from Postgres  
> servers to DNS servers to mail servers (postfix) under pretty  
> consistent load pushing lots and lots of data both network and to disk.

AOL! 6.3 with gmirror is rock solid here for web, mail, dns and db. No
bge here, but still, I haven't seen 6.3 glitch once.

/Mike

-- 
Michael Gratton <[EMAIL PROTECTED]> 
Quuxo Software 


signature.asc
Description: This is a digitally signed message part

Re: MFC of em/igb drivers

[sthaug]

> Have you tried disabling speed and duplex negotiation and explicitly
> stating speed and duplex like so?
> 
> ifconfig_em0="... media 1000baseTX mediaopt full-duplex"

Disagree with this piece of advice.

> Cisco switches have a notorious history of not being "friendly" with
> non-Cisco hardware.  Forcing duplex on both ends of the link (that means
> on both the host side, and the Cisco side!) usually fixes it.

I might have said the same myself five years ago. But this is 2008, and
we have autoneg as default on all ports (even at 100 Mbps). Our Cisco
switch ports (and we have a *lot* of them) work just fine with autoneg.

Note that GigE is different from FE here - autoneg is a compulsory part
of the GigE standard, while it's not compulsory for FE. The only GigE
ports that have needed anything else were some pre-standard GigE ports.

Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[nvidia | shared irq] umass disconnects [was: panic dd-ing from a USB "disk" ]

[Arno J. Klaassen]

Mikhail Teterin <[EMAIL PROTECTED]> writes:

> Hello!
> 
> I had some troubles mounting the filesystem from:
> 
>   da0 at umass-sim0 bus 0 target 0 lun 0
>   da0:  Removable Direct Access SCSI-2 device 
>   da0: 1.000MB/s transfers
>   da0: 3886MB (7959552 512 byte sectors: 255H 63S/T 495C)
> 
> and decided to just dd the entire da0 to a file, so that the camera
> can be disconnected:
> 
>   dd if=/dev/da0 of=/home/mi/da0.dd bs=16384
> 
> The dd-ing was proceeding slowly (600Kb/s) and I stopped watching it...
> 
> The machine paniced about an hour later (at 0:52). The timestamp on
> /home/mi/da0.dd was 23:45, it was only about 500Mb in size.
> 
> The stack is below. Would anybody like to look at the complete
> vmcore dump?
> 
> The hardware is a quad Opteron with 8Gb RAM. Only 4Gb of these are
> used, because it runs 7.x/i386 from April 5th (without PAE) -- for
> the sake of NVidia's card.


I can easily produce a similar panic on a dual Opteron 185 with
3G of RAM and running 7-stable-amd64 on a (cheap) nvidia-based MB.
It runs gmirror on atapci1 and I attach a geli-encrypted
disk via usb. Both share irq 23.

Under heavy load ("periodic security" is enough ) it panics after
having disconnected umass0 ( kgdb trace below ) :

Unread portion of the kernel message buffer:
umass0: at uhub1 port 1 (addr 2) disconnected
(da1:umass-sim0:0:0:0): lost device
(pass1:umass-sim0:0:0:0): lost device
(pass1:umass-sim0:0:0:0): removing device entry


I'd be happy to provide more info.

Best, Arno


> Please, advise. Thanks!
> 
>   -mi
> 
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: 
> Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd".
> There is no member named pathname.
> Reading symbols from /boot/modules/nvidia.ko...done.
> Loaded symbols for /boot/modules/nvidia.ko
> Reading symbols from /opt/modules/fuse.ko...done.
> Loaded symbols for /opt/modules/fuse.ko
> 
> Unread portion of the kernel message buffer:
> umass0: at uhub0 port 6 (addr 2) disconnected
> (da0:umass-sim0:0:0:0): lost device
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 3; apic id = 03
> fault virtual address = 0x0
> fault code= supervisor write, page not present
> instruction pointer   = 0x20:0xc0449702
> stack pointer = 0x28:0xeb74b8bc
> frame pointer = 0x28:0xeb74b8dc
> code segment  = base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres 1, def32 1, gran 1
> processor eflags  = interrupt enabled, resume, IOPL = 0
> current process   = 13989 (dd)
> trap number   = 12
> panic: page fault
> cpuid = 3
> Uptime: 12d10h52m16s
> (da0:dead_sim0:0:0:0): Synchronize cache failed, status == 0x34, scsi status 
> == 0xc8
> Physical memory: 3054 MB
> Dumping 334 MB: (CTRL-C to abort)  (CTRL-C to abort)  (CTRL-C to abort)  
> (CTRL-C to abort)  (CTRL-C to abort)  (CTRL-C to abort)  (CTRL-C to abort)  
> (CTRL-C to abort)  319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 
> 79 63 47 31 15
> 
> #0  doadump () at pcpu.h:195
> 195   __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) #0  doadump () at pcpu.h:195
> #1  0xc0599f7b in boot (howto=260) at /ibm/src/sys/kern/kern_shutdown.c:418
> #2  0xc059a449 in panic (fmt=0x104 )
> at /ibm/src/sys/kern/kern_shutdown.c:572
> #3  0xc077f60d in trap_fatal (frame=0xeb74b87c, eva=40)
> at /ibm/src/sys/i386/i386/trap.c:899
> #4  0xc077f9aa in trap_pfault (frame=0xeb74b87c, usermode=0, eva=0)
> at /ibm/src/sys/i386/i386/trap.c:812
> #5  0xc078035c in trap (frame=0xeb74b87c) at /ibm/src/sys/i386/i386/trap.c:490
> #6  0xc076637b in calltrap () at /ibm/src/sys/i386/i386/exception.s:139
> #7  0xc0449702 in xpt_done (done_ccb=0xc690a000)
> at /ibm/src/sys/cam/cam_xpt.c:4856
> #8  0xc044b15c in xpt_action (start_ccb=0xc690a000)
> at /ibm/src/sys/cam/cam_xpt.c:3057
> #9  0xc04462b6 in cam_periph_runccb (ccb=0xc690a000, error_routine=0, 
> camflags=CAM_FLAG_NONE, sense_flags=1, ds=0xc6aea690)
> at /ibm/src/sys/cam/cam_periph.c:878
> #10 0xc0453aa1 in daclose (dp=0xcc862600)
> at /ibm/src/sys/cam/scsi/scsi_da.c:714
> #11 0xc0549b2e in g_disk_access (pp=0xc7e12680, r=0, w=0, e=Variable "e" is 
> not available.)
> at /ibm/src/sys/geom/geom_disk.c:152
> #12 0xc054ec4d in g_access (cp=0xc8a90380, dcr=-1, dcw=0, dce=0)
> at /ibm/src/sys/geom/geom_subr.c:748
> #13 0xc05490f3 in g_dev_close (dev=0xca1dad00, flags=Variable "flags" is not 
> available.)
> at /ibm/src/sys/geom/geom_dev.c:217
> #14 0xc0531f69 in devfs_close (ap=0xeb74ba94)

Java binaries for FreeBSD 7

[Stefan Lambrev]

Greetings,

From http://www.freebsdfoundation.org/
"We are working on providing Java 1.6 support for FreeBSD 6.3 and 7.0. 
The binaries for 7.0 will be available by June 1."


Any news? :) Where I can read more?

P.S. I understand that this is not the mailing list to ask, but I can't 
find better.


--

Best Wishes,
Stefan Lambrev
ICQ# 24134177
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

6.3 stability and freebsd-update (was: Re: challenge: end of life for 6.2 is premature with buggy 6.3)

[Royce Williams]

>> On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote:
>>
>>>  Speaking just for myself, I'd love to get a general response from
>>> people who have run servers on both as to whether 6.3 is on average
>>> more stable than 6.2.  I really haven't gotten any clear impression as

6.3 has been stable for me.  I've been running since April on DL380
G2, Dell 2450, Supermicro 5015M-MF and 5015T-PR, and some older Intel
815E boards.  My bge(4) NICs are detected as Broadcom BCM5703 A2 and
BCM5704 A2, with no issues.  Running gmirror with no issues.

Someone mentioned freebsd-update earlier in the thread.  I'd like to
take a moment to plug it, since making it easy to move to 6.3 seems
topical.  I got a little long-winded, so here's an executive summary:

freebsd-update is good; business case for more hardware; updating in
'hybrid' mode with custom kernels and stock userland; using kernel
config 'includes' to save additional effort.


I prefer freebsd-update over the buildworld and then
installworld-over-NFS routine, centralized rsyncs, or anything else.
I used freebsd-update to uplift the systems above, and also just
bumped sixteen more from 6.2.  Worked like a charm.  Its 'rollback'
option is also very handy, for obvious reasons.

Based on how much time I save with freebsd-update, I can make a
business case for buying another box for a farm, rather than rolling
my own kernels and eking out xx% of additional performance.  Once ULE
gets into 7.x-RELEASE, I probably won't even have to do that.

For systems that require a custom kernel, we still patch everything
else with freebsd-update.  When freebsd-update detects the non-stock
kernel, it warns you to install a kernel from the target release.  If
that scares you, you can swap in a stock kernel from the current
release (saved off, or from the release media or FTP) and then
upgrade.  When finished, save off the new stock kernel for future
upgrades, and then rebuild your custom kernel.  (Anybody else doing
anything like this, or something better?)

I also recommend starting your kernel config with 'include SMP' (or
GENERIC or PAE or whatever).  If you use nocpu, nooptions,
nomakeoptions, nodevice etc. to turn off what you don't need, your
config is reduced to a 'diff' of sorts against the stock config.  Our
kernel configs are now ~17 lines, can be grokked at a glance, and
should change little from release to release.  Here's a stub of an
example that uses most of the knobs:

include SMP# Inherit SMP (which inherits GENERIC).

nocpu   I486_CPU   # Disable old CPU support; see tuning(7).
nocpu   I586_CPU
ident   SMP-GENERIC_CUSTOM_FOO  # Inherit ident, custom name.

nomakeoptionDEBUG  # Do not build with gdb(1) debug symbols.

nooptions   SCHED_4BSD # Do not use the 4BSD scheduler;
options SCHED_ULE  #   use ULE schedule instead.

# ALTQ support
options ALTQ
options ALTQ_CBQ   # Class Bases Queuing (CBQ)
options ALTQ_RED   # Random Early Detection (RED)
options ALTQ_RIO   # RED In/Out
options ALTQ_HFSC  # Hierarchical Packet Scheduler (HFSC)
options ALTQ_PRIQ  # Priority Queuing (PRIQ)
options ALTQ_NOPCC # Required for SMP build

# Devices for pf
device  pf # PF
device  pflog  # pflog
device  pfsync # pfsync


Use 'nodevice' to turn off devices worth leaving out, but only as many
as are worth the effort.

If you haven't already considered freebsd-update, either for the whole
system or just userland, I highly recommend it.  These days, the gain
has to be pretty significant for me to want to go back to making
world.  For our PXE installs using custom install.cfg, we can go from
bare metal to a fully patched vanilla system in four minutes on modern
hardware!  The novelty of that still hasn't worn off. :-)

It's more efficient (and probably safer?) to use freebsd-update
against a binary install rather than against local compilation.  And
if you're bumping major versions (6.x -> 7.x), you still have to
rebuild your ports.  But try it in your lab or for your next
deployment.  You can easily convert a freebsd-updated system to a
makeworld system, if necessary.

And thanks again, Colin!

Royce

-- 
Royce D. Williams   - http://royce.ws/
  Inspiration exists, but it has to find us working. - Pablo Picasso
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.3 stability and freebsd-update (was: Re: challenge: end of life for 6.2 is premature with buggy 6.3)

[Brooks Davis]

On Fri, Jun 06, 2008 at 11:34:01AM -0800, Royce Williams wrote:
> >> On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote:
> >>
> >>>  Speaking just for myself, I'd love to get a general response from
> >>> people who have run servers on both as to whether 6.3 is on average
> >>> more stable than 6.2.  I really haven't gotten any clear impression as
> 
> 6.3 has been stable for me.  I've been running since April on DL380
> G2, Dell 2450, Supermicro 5015M-MF and 5015T-PR, and some older Intel
> 815E boards.  My bge(4) NICs are detected as Broadcom BCM5703 A2 and
> BCM5704 A2, with no issues.  Running gmirror with no issues.
> 
> Someone mentioned freebsd-update earlier in the thread.  I'd like to
> take a moment to plug it, since making it easy to move to 6.3 seems
> topical.  I got a little long-winded, so here's an executive summary:
> 
> freebsd-update is good; business case for more hardware; updating in
> 'hybrid' mode with custom kernels and stock userland; using kernel
> config 'includes' to save additional effort.
> 
> 
> I prefer freebsd-update over the buildworld and then
> installworld-over-NFS routine, centralized rsyncs, or anything else.
> I used freebsd-update to uplift the systems above, and also just
> bumped sixteen more from 6.2.  Worked like a charm.  Its 'rollback'
> option is also very handy, for obvious reasons.
> 
> Based on how much time I save with freebsd-update, I can make a
> business case for buying another box for a farm, rather than rolling
> my own kernels and eking out xx% of additional performance.  Once ULE
> gets into 7.x-RELEASE, I probably won't even have to do that.
> 
> For systems that require a custom kernel, we still patch everything
> else with freebsd-update.  When freebsd-update detects the non-stock
> kernel, it warns you to install a kernel from the target release.  If
> that scares you, you can swap in a stock kernel from the current
> release (saved off, or from the release media or FTP) and then
> upgrade.  When finished, save off the new stock kernel for future
> upgrades, and then rebuild your custom kernel.  (Anybody else doing
> anything like this, or something better?)

Alternativly, you can edit freebsd-update.conf and tell it to not update your
kernel on those machines.

You can also exclude particular files.  We use this to keep from
updating libc directly on some machines where we're using modified RPC
timings to improve NIS performance in the face of occataionl packet
loss.

-- Brooks

> GENERIC or PAE or whatever).  If you use nocpu, nooptions,
> nomakeoptions, nodevice etc. to turn off what you don't need, your
> config is reduced to a 'diff' of sorts against the stock config.  Our
> kernel configs are now ~17 lines, can be grokked at a glance, and
> should change little from release to release.  Here's a stub of an
> example that uses most of the knobs:
> 
> include SMP# Inherit SMP (which inherits GENERIC).
> 
> nocpu   I486_CPU   # Disable old CPU support; see tuning(7).
> nocpu   I586_CPU
> ident   SMP-GENERIC_CUSTOM_FOO  # Inherit ident, custom name.
> 
> nomakeoptionDEBUG  # Do not build with gdb(1) debug symbols.
> 
> nooptions   SCHED_4BSD # Do not use the 4BSD scheduler;
> options SCHED_ULE  #   use ULE schedule instead.
> 
> # ALTQ support
> options ALTQ
> options ALTQ_CBQ   # Class Bases Queuing (CBQ)
> options ALTQ_RED   # Random Early Detection (RED)
> options ALTQ_RIO   # RED In/Out
> options ALTQ_HFSC  # Hierarchical Packet Scheduler (HFSC)
> options ALTQ_PRIQ  # Priority Queuing (PRIQ)
> options ALTQ_NOPCC # Required for SMP build
> 
> # Devices for pf
> device  pf # PF
> device  pflog  # pflog
> device  pfsync # pfsync
> 
> 
> Use 'nodevice' to turn off devices worth leaving out, but only as many
> as are worth the effort.
> 
> If you haven't already considered freebsd-update, either for the whole
> system or just userland, I highly recommend it.  These days, the gain
> has to be pretty significant for me to want to go back to making
> world.  For our PXE installs using custom install.cfg, we can go from
> bare metal to a fully patched vanilla system in four minutes on modern
> hardware!  The novelty of that still hasn't worn off. :-)
> 
> It's more efficient (and probably safer?) to use freebsd-update
> against a binary install rather than against local compilation.  And
> if you're bumping major versions (6.x -> 7.x), you still have to
> rebuild your ports.  But try it in your lab or for your next
> deployment.  You can easily convert a freebsd-updated system to a
> makeworld system, if necessary.
> 
> And thanks again, Colin!
> 
> Royce
> 
> -- 
> Royce D. Williams   - http://royce.ws/
>   Inspiration exists, but it has to find us working. - Pablo Picasso
> ___
> freebsd-stable@freebsd.org mailing li

6.2-STABLE => 7.0-STABLE Upgrade root partition more full

[Gavin Spomer]

I successfully did my first FreeBSD upgrade yesterday after looking at the 
manual, and cross referencing with Googling and getting help from our network 
engineer here at CWU. Before the upgrade, running df showed:

Filesystem  1K-blocksUsed Avail Capacity  Mounted on
/dev/da0s1a507630   7766238935817%/
devfs   1   1 0   100%/dev
/dev/da0s1e507630 588466432 0%/tmp
/dev/da0s1f 268217320 4866120 241893816 2%/usr
/dev/da0s1d   4298926  162066   3792946 4%/var

Now it shows:

Filesystem  1K-blocksUsed Avail Capacity  Mounted on
/dev/da0s1a507630  18483428218640%/
devfs   1   1 0   100%/dev
/dev/da0s1e507630 426466594 0%/tmp
/dev/da0s1f 268217320 5514844 241245092 2%/usr
/dev/da0s1d   4298926  187570   3767442 5%/var

Notice the the increase in the root partition. Should I have made this 
partition bigger when I first installed? Is there any cleaning up I can do 
after version upgrades? I would've thought /usr would be the one that grew 
more, but then again my /usr partition is fairly sizeable. Does 7.0 just take 
up a lot more of the root partition than 6.2?

- Gavin


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Java binaries for FreeBSD 7

[Pollywog]

On Friday 06 June 2008 19:39:59 Stefan Lambrev wrote:
> Greetings,
>
>  From http://www.freebsdfoundation.org/
> "We are working on providing Java 1.6 support for FreeBSD 6.3 and 7.0.
> The binaries for 7.0 will be available by June 1."
>
> Any news? :) Where I can read more?
>
> P.S. I understand that this is not the mailing list to ask, but I can't
> find better.

Perhaps here

http://www.freebsd.org/java/
___
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-STABLE => 7.0-STABLE Upgrade root partition more full

[Clifton Royston]

On Fri, Jun 06, 2008 at 11:37:51AM -0700, Gavin Spomer wrote:
> I successfully did my first FreeBSD upgrade yesterday after looking at the 
> manual, and cross referencing with Googling and getting help from our network 
> engineer here at CWU. Before the upgrade, running df showed:
> 
> Filesystem  1K-blocksUsed Avail Capacity  Mounted on
> /dev/da0s1a507630   7766238935817%/
> devfs   1   1 0   100%/dev
> /dev/da0s1e507630 588466432 0%/tmp
> /dev/da0s1f 268217320 4866120 241893816 2%/usr
> /dev/da0s1d   4298926  162066   3792946 4%/var
> 
> Now it shows:
> 
> Filesystem  1K-blocksUsed Avail Capacity  Mounted on
> /dev/da0s1a507630  18483428218640%/
> devfs   1   1 0   100%/dev
> /dev/da0s1e507630 426466594 0%/tmp
> /dev/da0s1f 268217320 5514844 241245092 2%/usr
> /dev/da0s1d   4298926  187570   3767442 5%/var
> 
> Notice the the increase in the root partition. Should I have made
> this partition bigger when I first installed? Is there any cleaning
> up I can do after version upgrades? I would've thought /usr would be
> the one that grew more, but then again my /usr partition is fairly
> sizeable. Does 7.0 just take up a lot more of the root partition than
> 6.2?

  Yes, it just does.  It should not keep expanding, though.

  IMHO, you should still be fine as long as you've got /tmp, /usr/,
/var, and the home directories residing on other partitions.  If you're
using /home under / for home directories, you might want to move it to
/usr/home and symlink /home to it.

  -- Clifton

-- 
Clifton Royston  --  [EMAIL PROTECTED] / [EMAIL PROTECTED]
   President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services
___
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-STABLE => 7.0-STABLE Upgrade root partition more full

[Skip Ford]

Gavin Spomer wrote:
> I successfully did my first FreeBSD upgrade yesterday after looking at the 
> manual, and cross referencing with Googling and getting help from our network 
> engineer here at CWU. Before the upgrade, running df showed:
> 
> Filesystem  1K-blocksUsed Avail Capacity  Mounted on
> /dev/da0s1a507630   7766238935817%/
> devfs   1   1 0   100%/dev
> /dev/da0s1e507630 588466432 0%/tmp
> /dev/da0s1f 268217320 4866120 241893816 2%/usr
> /dev/da0s1d   4298926  162066   3792946 4%/var
> 
> Now it shows:
> 
> Filesystem  1K-blocksUsed Avail Capacity  Mounted on
> /dev/da0s1a507630  18483428218640%/
> devfs   1   1 0   100%/dev
> /dev/da0s1e507630 426466594 0%/tmp
> /dev/da0s1f 268217320 5514844 241245092 2%/usr
> /dev/da0s1d   4298926  187570   3767442 5%/var
> 
> Notice the the increase in the root partition. Should I have made this 
> partition bigger when I first installed? Is there any cleaning up I can do 
> after version upgrades? I would've thought /usr would be the one that grew 
> more, but then again my /usr partition is fairly sizeable. Does 7.0 just take 
> up a lot more of the root partition than 6.2?

7.0 installs debugging symbols for the kernel and modules by default.
You can avoid that by defining INSTALL_NODEBUG during installkernel.
If already installed, you can delete the symbol files without causing
problems as long as you don't need to debug the kernel.

Also, when you install a new kernel, the old kernel is saved as
kernel.old so you now have 2 kernels in /boot instead of one.  If
you're positive the new kernel works fine, the old kernel can be
removed as that's only used to recover from a new kernel with problems.

But, your space really isn't that close to the limit, IMO.  You
appear to have enough space to have an old and new kernel installed
both with symbols, so I'd leave it as is in case you need to debug
something or boot the old kernel.  You can always take care of it
later if you're about to run out of space.  Why do today what you
can put off 'til tomorrow?

Also, consider reading UPDATING before every upgrade.  The entry for
20060118 covers this issue.

-- 
Skip
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

TMPFS: File System is Full

[Lin Jui-Nan Eric]

Hi,

I found when we exhaust memory, tmpfs will not be able to write
anything into it and cannot mount it.
I use ZFS and TMPFS at the same time.

Florence# cd /usr/src && make buildworld > /dev/null &
Florence# uname -a
FreeBSD Florence.tamama.org 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #5:
Mon May  5 00:36:32 CST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/KERNEL  amd64
Florence# mount -t tmpfs -o rw,size=1024000 tmpfs /tmp/tmpfs
mount: tmpfs : No space left on device

first 5 lines of top:

last pid: 26893;  load averages:  1.50,  1.58,  1.48
up 12+01:43:49  05:40:51
146 processes: 2 running, 144 sleeping
CPU states: % user, % nice, % system, % interrupt, % idle
Mem: 406M Active, 574M Inact, 1775M Wired, 83M Cache, 214M Buf, 126M Free
Swap: 1024M Total, 1024M Free


I think there should be a "lower bound" size limit. Does TMPFS use
kernel-space memory?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: freebsd-update 6.2-R -> 6.3-B1 rollback failed

[Miroslav Lachman]

Colin Percival wrote:

Jan Henrik Sylvester wrote:


In short, as long as you don't build a custom kernel but call it
"GENERIC" or
"SMP", FreeBSD Update should automatically DTRT.


That is exactly my question. On 6.2-RELEASE, I sometimes used a modified
ld-elf.so.1 or a single patched module without recompiling the kernel.
What does using freebsd-update (accidentally or deliberately) do in that
case?  By accident, I discovered that it does not always fail. Does it
skip the modified files, overwrite them with new versions, or overwrite
them with an unpredictable bdiff merge that is likely garbage?



Depending on the UpdateIfUnmodified option in freebsd-update.conf, it will
either update files to "clean" new versions or print a warning message and
not touch them.

There's also an IgnorePaths directive which you can use to tell FreeBSD
Update not to touch some files (even if they haven't been modified locally).

FreeBSD Update will never produce mangled files as a result of applying a
bsdiff patch to the wrong file -- it checks file hashes before and after
applying patches and gracefully falls back to downloading complete files
if it can't generate a file via patching.


Is it possible to configure freebsd-update to not remove old kernel 
directory and just rename it to kernel.old or something else?
Two times I end up with unbootable machine (upgraded from 6.3 to 7.0 - 
7.x version kernel always hangs on this machine, even with CD boot) and 
then I must use bootable CD / flashdisk with old 6.x kernel to be able 
to run freebsd-update rollback.
It will be useful if one can choose to leave old kernel in boot 
directory to be able to boot it if something goes wrong.


Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Java Status

[Deb Goodkin]

Dear Stefan,

I'm responding to your inquiry about the Java binaries. I just updated 
our website with the current status. We have completed the certification 
testing of Java 1.6 on FreeBSD 7. We are now waiting for approval from 
Sun. We anticipate it to take another two weeks.


Please let me know if you have any other questions.

Sincerely,

Deb Goodkin
Director of Operations
The FreeBSD Foundation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

[Paul Schmehl]

--On June 6, 2008 11:53:49 AM +0200 Manfred Usselmann 
<[EMAIL PROTECTED]> wrote:


What you are saying sounds like a contradiction to me. On one side it
is just a hobby site and generates no income and on the other hand it
is a critical server with millions of hits and the box can't even go
down for a short time.

What happens in case lets say your harddisk crashes? Something which is
not an exactly rare case...



Actually, that happened to us a couple of years ago, on the old server 
while it still the only server, and I was on vacation 1600 miles away.  We 
ended up having to pay the hosting company to fix the hardware problem and 
reinstall FreeBSD (which they unfortunately did a lousy job of), and then 
I rebuilt the server and restored it to service over a dialup account 
while on vacation.


Many of our users are retired old guys who can barely figure out how to 
use a computer.  When the site goes down, some of them claim to go into 
withdrawal.  The total downtime for that incident was about two days, and 
they "suffered" greatly.



If the users are not paying for the service they should be able to
accept a downtime, may it be scheduled or even completely unexpected.
Or pay / donate for a more reliable service (Redundant server as hot
standby / testbed etc.).



Actually, it was the owners who had to be convinced to accept donations 
from the users, who were all too willing to help.  The new server was 
purchased with those donations.  Maybe some day we *will* be able to 
afford redundancy.


Paul Schmehl
If it isn't already obvious,
my opinions are my own and not
those of my employer.

Re: challenge: end of life for 6.2 is premature with buggy 6.3

[Paul Schmehl]

--On June 6, 2008 3:08:25 PM +0200 Dag-Erling Smørgrav <[EMAIL PROTECTED]> 
wrote:


Paul Schmehl <[EMAIL PROTECTED]> writes:

[...] I reacted in anger because I felt the OP was being savagely
attacked rather than being responded to with professionalism.  Later
in the thread some folks got around to asking which PRs he was
referring to, but that was after attacking him for having the temerity
to suggest that perhaps 6.2 shouldn't be EOL.  [...]  I don't recall
him ever refusing.  I think after his initial post he's been forced to
defend himself from attack from 360 degrees.  [...]


I came in late, and thus had the benefit of reading most of thread in
context rather than piece by piece over time, and in my opinion, the
above is a gross misrepresentation.  I think you need to go back and
re-read the thread from the beginning.  Here, let me help you.


Thanks for the help.

My point still stands.  I think the behavior of the developers on the 
lists should be of as high a quality as the work they do on the OS (which, 
as I have stated, is first rate.)  Descending to the levels that some have 
(some of which you quote here) reflects poorly on the OS and its 
developers.


The fact that FreeBSD is open source does not negate the fact that its 
users are its customers and should be treated with respect, 
professionalism and yes, patience.


And again, I am trying neither to excuse nor to defend Jo's behavior. 
That's his gauntlet.  I am saying that the fact that developers possess a 
unique and valuable skill that is much appreciated by those of us who use 
the product of their labor does not excuse or justify some of the boorish 
behavior that was exhibited in this thread - regardless of how insulting 
one may have felt Jo's responses were.


Since a lot of people seem to want to pontificate without doing much of 
anything helpful, allow me to bring this discussion back to Jo's point:




That url lists 6 serious problems for bge and 3 non-critical problems, 
some dating to more than two years ago.  Two were patched, one is 
suspended and 6 are still open; four of those critical.




That url lists 1 serious problem and 3 non-critical problems with gmirror, 
all of which remain open.




That url refers to locking problems that cause kernel panics using the twe 
driver.




That url refers to a hang that renders a system unusable when using the 
twa driver.


Jo's concerns about updating to 6.3 rather than sticking with a system 
that's working for him don't seem unreasonable to me.  Do they to you?


Furthermore, it seems the reaction of developers, that he wasn't being 
specific enough are rendered moot by the urls above, which were easily 
accessed by me, someone with little knowledge at all of two of the three 
issues.  So, rather than berating Jo for not producing PRs, wouldn't it 
have been more professional to list the relevant PRs (just as I have done, 
which took me less time than the multiple angry responses to Jo took the 
involved developers) and ask him which of them gave him the greatest 
concerns?


What's the point of the constant demands to either produce specific 
relevant information of STFU?  Are the developers trying to impress the 
list with their professionalism?  Their patience?  Their knowledge?


If you're offended that I hold the developers to a higher standard than I 
do the users, then I plead guilty as charged and believe I am correct to 
do so.


As to your specific points:


I'm sorry that the FreeBSD project failed to conform to your
expectations.  However, I invite you to actually try 6.3 for yourself
instead of assuming that it will fail.


This is the crux of the matter - Jo is complaining about software he
hasn't even tried.  There is absolutely no way anybody can help him
until he actually tries 6.3 and reports any actual bugs and regressions
he finds."


Not only is this wrong, but it completely misses the point.  Why should Jo 
have to upgrade to find out if his servers will fail under the conditions 
already articulated in existing, unresolved PRs that affect hardware that 
he is presently using?  That's a bit like saying, "Buy this new car.  Sure 
it has bugs that could easily directly affect you, but what's the chance 
you'll encounter them?  in the off chance that they do, then you can help 
us resolve them."


You reveal extreme naivette when you state this:


That is also untrue.  None of these are "bugs tha

TMPFS: File System is Full

[Lin Jui-Nan Eric]

Hi,

I found when we exhaust memory, tmpfs will not be able to write
anything into it and cannot mount it.
I use ZFS and TMPFS at the same time.

Florence# cd /usr/src && make buildworld > /dev/null &
Florence# uname -a
FreeBSD Florence.tamama.org 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #5:
Mon May  5 00:36:32 CST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/KERNEL  amd64
Florence# mount -t tmpfs -o rw,size=1024000 tmpfs /tmp/tmpfs
mount: tmpfs : No space left on device

first 5 lines of top:

last pid: 26893;  load averages:  1.50,  1.58,  1.48
   up 12+01:43:49  05:40:51
146 processes: 2 running, 144 sleeping
CPU states: % user, % nice, % system, % interrupt, % idle
Mem: 406M Active, 574M Inact, 1775M Wired, 83M Cache, 214M Buf, 126M Free
Swap: 1024M Total, 1024M Free

I think there should be a "lower bound" size limit. Does TMPFS use
kernel-space memory?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

[Adrian Chadd]

2008/6/7 Paul Schmehl <[EMAIL PROTECTED]>:

> Not only is this wrong, but it completely misses the point.  Why should Jo
> have to upgrade to find out if his servers will fail under the conditions
> already articulated in existing, unresolved PRs that affect hardware that he
> is presently using?  That's a bit like saying, "Buy this new car.  Sure it
> has bugs that could easily directly affect you, but what's the chance you'll
> encounter them?  in the off chance that they do, then you can help us
> resolve them."

The software is Free. The car was Bought (or suggested to be bought.)

Re-visit the analogy with a free car that a friend wants to give you.
(Car analogies suck.)


> Trust me.  From a server admin's perspective, a bug affects you if it exists
> in hardware you use.  Whether or not you're actually using the OS is
> completely irrelevant.  Upgrading to the OS would be foolhardy.  Even
> testing it on a handful of boxes will not prove that it won't fail under
> load in production.  Anyone who has done testing knows it can only simulate,
> not duplicate, the conditions under which production servers run.  I
> personally have experienced catastrophic failures after extensive testing
> that revealed no problems.

You're using free software. This translates to "lots of people have
put in a lot of effort to provide something to the community which
they can use, at no cost, if it suits them."

As said before, the reason FreeBSD isn't supporting older 6.x releases
anymore is because there's just no manpower to do so.


> Yes, I think some perspective is needed here, but it's not only Jo who needs
> it nor is it he who needs it the most.
>
> I've lectured enough.  If anyone doesn't get the point by now further
> explanation isn't going to help.

I still don't think you get it. FreeBSD is a community. A community
works when enough people contribute positively towards furthering the
goals of the project. Jo is a user. He sounds like he is using it in
some reasonably critical and money-earning roles. Jo can participate
by testing stuff on test hardware, reporting back issues and working
with the community. Bitching about there being no long-term support
for releases isn't constructive. Some developer comments may not be
constructive either, but this is a -community project-. Join the
-community- and help out.

It doesn't matter if running a long-term support project would be
beneficial for a certain subset of the userbase, its a losing
situation to cater to them unless they somehow contribute back to the
community.


adrian


-- 
Adrian Chadd - [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"