Re: Hyper-V Integration Components Patch for FreeBSD 8.2, 8.3, 9.0 and 9.1-BETA1

[Antony Mawer]

Great, really looking forward to trying this out! Have you noticed any
difference with larger file systems using the HyperV block driver? Since
8.x the standard file systems seem to suffer corruption with > 40gb, which
is a show stopper for our clients wanting to deploy on HyperV. I hoped this
might solve the problem...?

-- Antony

On Monday, August 13, 2012, Chris Knight wrote:

> Hello,
>
> I've created some patchsets based on the beta release of the Hyper-V
> integration components for FreeBSD.
>
> The patchsets are for 8.2, 8.3, 9.0 and 9.1-BETA1 and can be found here:
>
> http://blog.chrisara.com.au/2012/08/hyper-v-integration-components-for_13.html
>
> Although the Hyper-V kernel modules compile, they'll cause a kernel
> panic if loaded, but I got them built cleanly to allow for easy kernel
> swapping using nextboot.
> Using GEOM labels makes it easy to swap between a Hyper-V enabled
> kernel and a non-Hyper-V enabled kernel.
>
> It's also worth noting that the Hyper-V network driver is flaky - UDP
> works fairly well, but TCP is very flaky. Haven't yet got to the root
> cause of this.
>
> The storage performance increase is very nice, as is the heartbeat and
> shutdown capabilities. I've yet to check if KVP functionality is
> included.
>
>
> --
> Regards,
> Chris Knight
> ___
> freebsd-stable@freebsd.org  mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to 
> "freebsd-stable-unsubscr...@freebsd.org
> "
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Recommendation for Hyervisor to host FreeBSD

[Antony Mawer]

On Thu, Jul 5, 2012 at 10:43 PM, Rainer Duffner  wrote:
> Am Thu, 05 Jul 2012 12:43:06 +0100
> schrieb Pete French :
>
>> So, my work surprise for a Thursday morning is an urgent requirement
>> to see if we can run a set of FreeBSD machines under virtualised
>> servers. I have not done this before personally, but I notice from
>> post here that it doesnt seem uncommon, and I see Xen related commits
>> flowing past, so I am guessing it is doable.
>>
>> So, for running 8 or 9 STABLE can anyone recommend which hypervisor
>> works best, and is 8 or 9 better as the OS to run ? Am doing a bit
>> of research myself, but nothing beats persoanl experience in these
>> matters!
>
>
>
> AFAIK, there are no VMware-tools for FreeBSD9 (yet).
> So, if you need to use ESXi/vSphere, then stay with 8.3 for the time
> being.

We have had a lot of success and good performance deploying under ESXi
- often without the VM tools package installed.

> Also, full, native support for MSFT-HyperV is coming to FreeBSD9.

Isn't this supposed to be on 8.2 and 8.3 as well (per the official
announcement)? I am awaiting further announcement on this as I have a
lot of our clients / prospective clients who run HyperV environments
who want to deploy on this. Last time we tried on 8.1 the OS would
crash with memory corruption errors, which happened across multiple
test systems...

http://blogs.technet.com/b/openness/archive/2012/05/10/freebsd-support-on-windows-server-hyper-v.aspx

-- Antony
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: kern/143370: splash_txt ASCII splash screen module

[Antony Mawer]

On Thu, Jun 30, 2011 at 1:10 PM, jhell  wrote:
> On Thu, Jun 30, 2011 at 12:47:45PM +1000, Antony Mawer wrote:
>> On Thu, Jun 30, 2011 at 11:33 AM, jhell  wrote:
>> > Most admins that I know don't bother with things like splash screens on
>> > 'production' equipment because its irrelevant to the actual server
>> > usage and unneeded overhead since the actual boot messages prove much
>> > more useful than some random ascii or bmp/pcx.
>>
>> They're embedded-style server systems at remote client sites, about
>> 1200 of them. The splash module is just a visual "nicety" which is
>> displayed during startup - at least providing some feedback as to what
>> the system is doing. These are systems aimed at a non-tech audience,
>> so those "niceties" count.
>>
>> The alternative to that was either standard kernel messages during
>> boot, or a silent boot, both of which tend to confuse the crap out of
>> non-tech end users.
>
> Yeah I agree. I originally downloaded your patch, I think it was for a
> 6.X system back then ~2008-09ish possibly even 7.X and twiddled with it
> for a bit playing around with all the funkiness of TheDraw and getting
> that good ole feeling of BBS days. But that's usually about as far as I
> go with things like that as you  could probably tell from above ;)
>
> I was going through my archive file directory probably last month and
> came across the copy of the program which made me remember that patch,
> funny coincidence that it comes back up now ;)
>
> I must say though having to use a reproducible .bin file over trying to
> figure out all the complexities of making a proper gzip'd xpm,bmp,pcx
> file was NICE!
>
> My first attempt ever making a splash image bmp was a fail due to manual
> reading problems but needless to say it was a pain. TheDraw nearly
> painless but how long can we seriously hold on to that program and will
> there ever be anything to replace it ?

I had to update our splash screen recently for $WORK, and have
recently shifted my primary desktop+laptop to a Mac. Thought I'd give
DOSBox a go and sure enough TheDraw fired up beautifully! You are
right about it being a flash back to the BBS days.

I have used DuhDraw (open source clone of TheDraw) under Linux many
many years ago; there's a port in graphics/duhdraw if anyone wanted to
try it out and see if it still works. In theory it should work just as
well as TheDraw...

Have been keeping this building in our local tree for all these years,
but figured that there must be some people out there who might like to
use it too...

-- Antony
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: kern/143370: splash_txt ASCII splash screen module

[Antony Mawer]

On Thu, Jun 30, 2011 at 3:04 AM, Torfinn Ingolfsen
 wrote:
> On Wed, 29 Jun 2011 22:50:15 +1000
> Antony Mawer  wrote:
>> Not sure if this is the right place to post it -- about 6 years ago I
>> put together a module which displays an ASCII splash screen on boot
>> (rather than the graphical splash_pcx and splash_bmp modules). We have
>> been running it in production since that time without issue.
>
> So, the difference between this and loader.conf's loader_logo construct is 
> that
> a) this is a proper splash screen module
> b) you can / must design your splash screen with a separate program (compared 
> to write / modify Forth code)
>
> Is my understanding correct?

Not quite. The loader_logo is only displayed at the boot screen, and
disappears as soon as the kernel begins booting. The splash module
effectively creates an "overlay" display which is placed on-screen
while the kernel probes devices and starts up, replacing the standard
startup messages. Think more along the lines of your OS boot screen on
Windows/Mac/Linux.

In our case, this provides a clean boot screen instead of confusing
probe messages (or silence if they're hidden) while the system starts,
which can be reassuring to a non-tech audience, and does so without
reliance on VESA support which doesn't always work on the systems we
work with.

The choice of file format was simply that it was an easy to use format
supported by ASCII drawing software that I was familiar with (TheDraw,
DuhDraw). There is nothing to stop someone adding support for a
different format of encoding if they wanted -- the same as someone
could write a splash_jpg or splash_gif module if they really wanted
to.

-- Antony
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: kern/143370: splash_txt ASCII splash screen module

[Antony Mawer]

On Thu, Jun 30, 2011 at 11:33 AM, jhell  wrote:
> Youve been running this in production... How often do these servers
> reboot ;¿ and is it to identify what is actually running on the machine
> so they are not confused with surrounding equipment ?
>
> Most admins that I know don't bother with things like splash screens on
> 'production' equipment because its irrelevant to the actual server
> usage and unneeded overhead since the actual boot messages prove much
> more useful than some random ascii or bmp/pcx.

They're embedded-style server systems at remote client sites, about
1200 of them. The splash module is just a visual "nicety" which is
displayed during startup - at least providing some feedback as to what
the system is doing. These are systems aimed at a non-tech audience,
so those "niceties" count.

The alternative to that was either standard kernel messages during
boot, or a silent boot, both of which tend to confuse the crap out of
non-tech end users.

-- Antony
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

kern/143370: splash_txt ASCII splash screen module

[Antony Mawer]

Hi all,

Not sure if this is the right place to post it -- about 6 years ago I
put together a module which displays an ASCII splash screen on boot
(rather than the graphical splash_pcx and splash_bmp modules). We have
been running it in production since that time without issue.

With the the code slush for 9.0 on the horizon, I thought it might
again be worth trying to see if someone is prepared to get this into
the tree so others can benefit from it. I have a PR open, kern/143370,
which includes the patch for the module; it is against 7.0 but has
been used largely unmodified since 4.x days. It currently builds on
8.x still fine as we are running it in production on 8.x for $WORK.

Summary of instructions from my previous post about this from ~18mths ago:

In case the list eats the patch, you can grab a copy of it here:

http://www.mawer.org/freebsd/splash_txt.patch

To give you an idea of what it looks like, here is a screenshot of a
quick generic FreeBSD splash screen I put together:

http://www.mawer.org/freebsd/splash_txt_1.png
http://www.mawer.org/freebsd/splash_txt_2.png

If you'd like to try it for yourself then the process to build it
should be something like this:

1. Download the attached patch
2. Create the required folders before applying the patch -- cd
/usr/src && mkdir sys/modules/splash/txt
3. Apply the patch -- patch < splash_txt.patch
4. Build the module -- cd sys/modules/splash/txt && make && make install

Once that's completed, you can configure it by adding the following to
loader.conf:

splash_txt_load="YES"
bitmap_load="YES"
bitmap_name="/boot/freebsd.bin"

I have uploaded two sample boot splash screens at
http://www.mawer.org/freebsd/freebsd1.bin and
http://www.mawer.org/freebsd/freebsd2.bin . The files can be produced
using TheDraw and saving in its Binary file format, which consists of
a sequence of 2 byte pairs. The first byte in a pair is the character
to draw on the screen, and the second is the colour/display attributes
to draw the character with.

If anyone else would like to try this out and has any feedback, or if
someone thinks it may be of interest to integrate into the tree please
let me know ...

Otherwise if anyone would like to help push this into the tree in time
for 9.0 would be great. It should be safe to MFC to 8.x as well -- as
I said we've been running it ever since 4.x days. I am sure others out
there would gain at least some (cosmetic) benefits from this!

-- Antony
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Gpart and gmirror 8.2 from 18 januari

[Antony Mawer]

On Sat, Jan 22, 2011 at 12:55 AM, Ivan Voras  wrote:
> On 21/01/2011 14:22, Andrey V. Elsukov wrote:
>>
>> On 21.01.2011 16:03, Ivan Voras wrote:
>>>
>>> On 21/01/2011 13:56, Johan Hendriks wrote:

 Ok the funny thing is, i get the same error on 8.1 Release (the corrupt
 error), but it boots,
 and all seems to work.
>>>
>>> Maybe the boot process was made to be more standard-compliant :)
>>
>> The most strangest is that UFS's label ufsid/4b9545d7d72d5019 is
>> represented
>> as whole disk where GPT is located.
>
> This is how glabel works - if anything within a provider recognizes it as
> its own (e.g. a file system), the whole provider is labeled for it.
>
> Or are you thinking about something else? If you first did gmirror, then
> gpt, then newfs, the UFS label should be created with the same data as the
> gpt partition, not the "whole disk".

On 8.0 (haven't checked 8.1 or later), I have systems running with
gmirror across two disks (say ad4 and ad6), with gpt then configured
over the top of this. I have noticed the occasional "GPT corrupt"
message on bootup on some of these systems - not sure if this is
because it looks at the disk device first at boot time and sees the
last sector is the gmirror metadata, rather than the GPT data?

They seem to operate without function, aside from the slightly scary
warning message.

To build these systems the following commands are used:

# Initialise the gmirror device
/sbin/gmirror label -b load gm0 ad4 ad6

# Partition using gpart
diskdev="mirror/gm0"
boot_offset="2032"
gpart add -l boot -t freebsd-boot -s 16 -b $boot_offset
$diskdev   # boot p1
gpart add -l root -t freebsd-ufs  -s 2G -b $root_offset
$diskdev   # /p2
gpart add -l swap -t freebsd-swap -s 4G
$diskdev   # swap p3
gpart add -l var  -t freebsd-ufs  -s 4G
$diskdev   # /var p4
gpart add -l usr  -t freebsd-ufs
$diskdev   # /usr p5

# Boot code
gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 $diskdev

# Mark partition active (older systems)
echo 'a 1' | fdisk -f - /dev/$diskdev

Any feedback welcome!

--Antony
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920

[Antony Mawer]

This may well be the same sort of issue that was discussed in this thread here:

http://lists.freebsd.org/pipermail/freebsd-hackers/2010-March/031004.html

In short, the Core i7 CPUs have a feature called "TurboBoost" where
the clock speed of one or more cores is boosted when other cores are
idle and in a C2 or C3 sleep status ... if the appropriate power
saving mode isn't active on the system (which I don't think FreeBSD
does by default?), the idle cores are never put into the appropriate
power saving state, and as a result TurboBoost never kicks in...

It _may_ be that Ubuntu configures this correctly whereas FreeBSD does
not (out of the box)?

Of course it may be something else entirely, but worth checking out...

--Antony

On Mon, Apr 12, 2010 at 7:31 PM, Adrian Chadd  wrote:
> Of course, what would be helpful is actually figuring out what is
> going on rather than some conjecture. :)
>
> With what he said, tweaking memory allocation under FreeBSD and/or
> linux would change the performance characteristics and either validate
> or disprove his assumptions?
>
>
> Adrian
>
> On 12 April 2010 12:12, Maho NAKATA  wrote:
>> Hi FreeBSD developers,
>> [the original article in Japanese can be found at
>> http://blog.goo.ne.jp/nakatamaho/e/b5f6fbc3cc6e1ac4947463eb1ca4eb0a ]
>>
>> *Abstract*
>> I compared the peak performance of FreeBSD 8.0/amd64 and Ubuntu 9.10 amd64 
>> using dgemm
>> (a linear algebra routine, matrix-matrix multiplication).
>> I obtained only 70% of theoretical peak performance on FreeBSD 8/amd64 and
>> almost 95% on Ubuntu 9.10 /amd64. I'm really disappointed.
>>
>> *Introduction*
>> I'm a friend of Gotoh Kazushige, the principal developers of GotoBLAS. He 
>> told me that
>> FreeBSD is not suitable OS for scientific computing or high performance 
>> computing. He says
>> (in Japanese and my translation):
>>
>>> I guess FreeBSD does page coloring, but I don't think FreeBSD considers 
>>> very large cache
>>> size which recent CPU has. Support of a very large cache on Linux is still 
>>> not very will
>>> sophisticated, but on *BSDs, its worst; they uses too fine memory 
>>> allocation method,
>>> so we cannot expect large continuous physical memory allocation.
>>> Moreover, process scheduling is not so nice as *BSD employs an algorithm 
>>> that
>>> changes physical CPUs in turn instead of allocating one core for such kind 
>>> of jobs.
>>> Take your own benchmark, and you'll see..
>>
>> *Result*
>> Machine: Core i7 920 (42.56-44.8Gflops) / DDR3 1066
>> OS: FreeBSD 8.0/amd64 and Ubuntu 9.10
>> GotoBLAS2: 1.13
>>
>> dgemm result
>> OS      : FLOPS           : percent in peak
>> FreeBSD : 32.0 GFlops     : 71%
>> Ubuntu  : 42.0-42.7GFlops : 93.8%-95.3%
>>
>> Thanks,
>> -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/
>>   Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt
>>
>>
>>
>>
>> ___
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>>
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: netboot issues, 8.0, mfsroot mount failure

[Antony Mawer]

On Thu, Feb 18, 2010 at 6:22 AM, Jeremy Chadwick
 wrote:
> On Tue, Feb 16, 2010 at 11:43:30PM -0500, Charles Sprickman wrote:
>> >Footnote: This is why I tell folks to zero out the first 8192 bytes of
>> >any disk they've previously installed FreeBSD on (even if the disk has
>> >no filesystems/slices on it).  The way FreeBSD determines the size of
>> >the disk differs in RELENG_8; I believe GEOM "figures it out" on its own
>> >now, while previous releases relied on the "c" slice.  The method I've
>> >recommended: do dd if=/dev/zero of=/dev/adX bs=512 count=16.
>>
>> Is it also advisable to blot out any old glabel stuff at the end of
>> the disk?  What's the math to get that?  Get a sector count for the
>> whole disk, set "bs" to 512 and "skip" to (sector count - 1)?
>
> I don't think the glabel data (which goes at the end of the disk) is
> relevant to the above problem I described.  You can erase it if you
> want, but I doubt it's responsible for warnings like "Disk geometry does
> not match label!" or situations where a user is re-using a disk (that
> had its slices created on RELENG_7) on RELENG_8 and experiences
> problems.  An alternative to the dd method might be to try "gpart
> destroy"; I haven't tried to see if relieves the problem.
>
> As far as how to erase the glabel metadata -- "glabel clear" is supposed
> to do this for you.  What I don't know is whether or not addition of a
> glabel decreases what GEOM thinks the total size of the disk is, so I
> can't say for certain doing some math + zeroing the last sector of the
> disk would actually work.

I have recently been using the following snippet in an install script
to zero out any existing gmirror/etc metadata before the install
proceeds (and potentially reconfigures a new gmirror etc):

# Specify the disk device to clear
diskdev="da0"

# Clear metadata from the last sector on the drive
echo "Clearing any GEOM metadata on drive..."
diskinfo=`diskinfo /dev/$diskdev`
sector_size=`echo $diskinfo | cut -f2 -d\ `
size_in_sectors=`echo $diskinfo | cut -f4 -d\ `
geom_offset=$(($size_in_sectors-1))
dd if=/dev/zero of=/dev/$diskdev bs=$sector_size
oseek=$geom_offset count=1 2> /dev/null

In preliminary testing it seems to do the job...

-- Antony
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[patch] New splash_txt module - support for ASCII splash(4) boot screens

[Antony Mawer]

Hi all,

I recently dusted off an old patch I put together years ago which adds
a new splash_txt decoder module for the splash(4) boot splash screen.
The module allows you to use a binary-format ASCII drawing (80x25) as
a boot splash screen rather than the graphical modes offered by
splash_bmp and splash_pcx. We have been and still are using it, but I
finally got around to adding the relevant changes to the splash(4) man
page and putting together some examples for wider testing. If it seems
of use to others it would be nice if someone would be interested in
committing it at some stage.

In case the list eats the patch, you can grab a copy of it here:

http://www.mawer.org/freebsd/splash_txt.patch

To give you an idea of what it looks like, here is a screenshot of a
quick generic FreeBSD splash screen I put together:

http://www.mawer.org/freebsd/splash_txt.png

If you'd like to try it for yourself then the process to build it
should be something like this:

1. Download the attached patch
2. Create the required folders before applying the patch -- cd
/usr/src && mkdir sys/modules/splash/txt
3. Apply the patch -- patch < splash_txt.patch
4. Build the module -- cd sys/modules/splash/txt && make && make install

Once that's completed, you can configure it by adding the following to
loader.conf:

splash_txt_load="YES"
bitmap_load="YES"
bitmap_name="/boot/freebsd.bin"

I have uploaded a sample boot splash screen at
http://www.mawer.org/freebsd/freebsd.bin . The files can be produced
using TheDraw and saving in its Binary file format, which consists of
a sequence of 2 byte pairs. The first byte in a pair is the character
to draw on the screen, and the second is the colour/display attributes
to draw the character with.

If anyone else would like to try this out and has any feedback, or if
someone thinks it may be of interest to integrate into the tree please
let me know ...

-- Antony


splash_txt.patch
Description: Binary data
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Any recommended Intel server motherboards?

[Antony Mawer]

The Intel boards all in all tend to be pretty well supported... we run
a number of S3200SHL boards (about to be EOL'd I believe) and older
S2000 series in production without any hitches. The basic Intel
soft-RAID on the entry level boards should be avoided (use gmirror or
similar if need be).

If you are looking at any of the boards with onboard SAS, this is
usually an LSI Logic based chipset (mfi driver from memory) and is
fine as far as RAID reliability goes (at least in our experience,
YMMV)...

-- Antony

On Mon, Oct 12, 2009 at 12:55 PM, Clifton Royston  wrote:
>  A client is asking me to recommend hardware for a mailserver; they're
> an OEM and whitebox builder, and would prefer to use an Intel server
> board which seems reasonable.  Are there any particularly recommended
> current models?
>
>  I seem to recall that Intel's RAID hardware is not that reliable, so
> I am assuming I should either recommend they use plain SATA or SAS
> drives, or steer them to an external RAID system with dedicated
> controller.  If that's changed, it would be nice to know.
>
> Parameters:
>
>  The system will not be very high-throughput, primarily fronting and
> acting as relay and storage queue for initially about 5000 mailboxes in
> 100+ domains.  All spam filtering will be handled on another box.
>
>  -- Clifton
>
> --
>    Clifton Royston  --  clift...@iandicomputing.com / clift...@lava.net
>       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 "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Network sysctl tuning [was Re: ZFSKnownProblems - needs revision?]

[Antony Mawer]

Freddie Cash wrote:
...
We've also heavily modified /etc/sysctl.conf and upped a bunch of the 
network-related sysctls.  Doing so increased our SSH throughput from ~30 
Mbits/sec across all connections to over 90 Mbits/sec per SSH connection.


Are you able to share any of these with the list? It would be useful to 
compare as a lot of these tunings people do individually and it would be 
good to allow others to test in their environments to see if they help, 
as well as potentially adding them to the tuning man-page.


-- Antony
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Request for testing: ata(4) MFC

[Antony Mawer]

Jeremy Chadwick wrote:

On Fri, Oct 10, 2008 at 04:58:55AM -0700, Jeremy Chadwick wrote:

On Sun, Oct 05, 2008 at 10:12:11PM -0700, Jeremy Chadwick wrote:

On Mon, Oct 06, 2008 at 09:03:20AM +0400, Andrey V. Elsukov wrote:

Jeremy Chadwick wrote:

Also, does your patch include any fixes (intentional or inadvertent) for
Intel MatrixRAID?  This has been a sore spot for FreeBSD for quite
some time, and I'm curious to know if that has been fixed.

There is only one fix for Intel Matrix RAID:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/121899

Ahh, yeah, I've seen that one as well.  I'll apply the patch and let you
know if the behaviour documented in the PR happens.

I'm sorry I haven't gotten around to testing this -- my day (night) job
has kept me incredibly busy, and I've had hardly any time at home to
work on personal projects.  It sucks.

I'll try to make time for testing either today or tomorrow.

...

Other items:

- Could someone provide an explanation of the 48-bit LBA addressing
  changes (see lines 988-1003 in the patch)?  I'd like to know what they
  do, and if further QA/testing is needed with this.


This is probably more a question for Søren...

I started looking at the moment, as the original 28->48bit crossover bug 
was in the same function not so long ago (ata-all.c rev1.280). The 
48-bit LBA changes are introduced from ata-all.c rev1.282, which was the 
port multiplier changes. The logic just doesn't seem quite right to it 
to me, but


I'm not an expert on the code or on ATA, so all of this could just be 
amateur mis-interpretation. From my reading of it, the code does this:


/*
 * Check to see if we need to use a 48-bit command in place of the
 * standard 28-bit command, and if so, substitute as appropriate
 */
IF ((request_lba_addr + lba_count) >= max addressable by 28-bit LBA
or lba_count > 256) and device supports 48-bit LBA THEN
/*
 * The request either:
 *
 *- extends past the 28-bit boundary
 *- is for more than 256 sectors
 *
 * which necessitates the use of 48-bit LBA. Translate commands
 * into their 48-bit equivalents.
 */
...
ELSEIF the device supports 48-bit lba:
/*
 * We prefer (need?) to use the 48-bit equivalents of these
 * commands regardless of what the LBA address of the reqest is
 */
   ...
END IF

In rev 1.282, the ATA_READ_NATIVE_MAX_ADDRESS was moved down to the 
"ELSE" case of the IF statement. In otherwords, when the request is 
beyond the 28-bit boundary, OR it's > 256 sectors, 
ATA_READ_NATIVE_MAX_ADDRESS won't be translated...


Søren, is this change intentional, or should it be also added to the 
switch statement in the top half of the IF block?


The ATA code appears to be very lightly commented, which no doubt is 
something of a barrier to entry to those who are not familiar with 
issues such as the above... would any volunteers be helpful to help 
comment and/or document some of the code? We would likely need to confer 
with Søren and others to ensure that our interpretation was accurate, 
but it would certainly make tracking down issues easier for those 
unfamiliar with the code...


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

Finding which GEOM provider is generating errors in a graid3

[Antony Mawer]

I have a FreeBSD 6.2-based server running a 1.2TB graid3 volume, which 
consists of 5x 320gb SATA hard drives. I've been getting errors in 
/var/log/messages from the graid3 volume, which I suspect means an 
underlying fault with one of the disks, but is there any way to decipher 
which one of these drives is throwing errors?


I've checked smartctl -a /dev/adXX but nothing shows up there.. I'm 
wondering if this is the infamous ata driver bug(s) that may be rearing 
its ugly head..


Also, does anyone know what "ZoneXXFailed" items in the graid3 list 
output mean?


Relevant output:

$ graid3 status
   NameStatus  Components
raid3/data1  COMPLETE  ad12
   ad14
   ad16
   ad18
   ad20

$ graid3 list
Geom name: data1
State: COMPLETE
Components: 5
Flags: VERIFY
GenID: 0
SyncID: 1
ID: 3700500186
Zone64kFailed: 791239
Zone64kRequested: 49197268
Zone16kFailed: 40204
Zone16kRequested: 1283738
Zone4kFailed: 12005939
Zone4kRequested: 2445799003
Providers:
1. Name: raid3/data1
   Mediasize: 1280291731456 (1.2T)
   Sectorsize: 2048
   Mode: r1w1e1
...

$ atacontrol list
...
ATA channel 6:
Master: ad12  Serial ATA v1.0
ATA channel 7:
Master: ad14  Serial ATA v1.0
ATA channel 8:
Master: ad16  Serial ATA v1.0
ATA channel 9:
Master: ad18  Serial ATA v1.0
ATA channel 10:
Master: ad20  Serial ATA v1.0


Output in /var/log/messages:


Aug 27 17:17:27 backup kernel: 
g_vfs_done():raid3/data1[READ(offset=160320159744, length=16384)]error = 5
Aug 27 17:25:45 backup kernel: 
g_vfs_done():raid3/data1[READ(offset=160320159744, length=16384)]error = 5
Aug 27 17:25:45 backup last message repeated 7 times
Aug 27 17:25:45 backup kernel: 
g_vfs_done():raid3/data1[READ(offset=160320176128, length=16384)]error = 5
Aug 27 17:25:45 backup last message repeated 22 times
Aug 27 17:25:45 backup kernel: 
g_vfs_done():raid3/data1[READ(offset=160320192512, length=16384)]error = 5
Aug 27 17:25:45 backup last message repeated 21 times
Aug 27 17:38:24 backup kernel: 
g_vfs_done():raid3/data1[READ(offset=160320176128, length=16384)]error = 5
Aug 27 17:38:26 backup last message repeated 4 times
Aug 27 17:46:02 backup kernel: 
g_vfs_done():raid3/data1[READ(offset=160320159744, length=16384)]error = 5
Aug 27 17:53:48 backup kernel: 
g_vfs_done():raid3/data1[READ(offset=160320159744, length=16384)]error = 5
Aug 27 17:53:48 backup last message repeated 7 times
Aug 27 17:53:48 backup kernel: 
g_vfs_done():raid3/data1[READ(offset=160320176128, length=16384)]error = 5
Aug 27 17:53:48 backup last message repeated 22 times
Aug 27 17:53:48 backup kernel: 
g_vfs_done():raid3/data1[READ(offset=160320192512, length=16384)]error = 5
Aug 27 17:53:49 backup last message repeated 21 times


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

Re: 7.0 issues fixed? upgrade timing?

[Antony Mawer]

Jeremy Chadwick wrote:
...

  [20080229] A change in the way that FreeBSD sends TCP options has been 
reported to cause odd interactions with some cable modem routers. While this 
issue is still under investigation, a change has been committed to HEAD that 
returns the option processing to that of FreeBSD 6. So far, this change has 
shown some promising results.


Do you have more details on this?  Open PR, or a thread I can read?  I'm
thinking it might be related to the net.inet.tcp.rfc1323 sysctl, but I'm
not sure.


See here:
http://groups.google.com/group/mailing.freebsd.net/browse_thread/thread/03e3965192fbc64c/48e037ab2717c7dd?lnk=raot

It's fixed in RELENG_7 as far as I'm aware:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c#rev1.141.2.5

but there was talk of it being an errata candidate for RELENG_7_0, which 
doesn't look like has happened just yet.


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

Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD

[Antony Mawer]

On 3/12/2007 8:50 PM, Alexey Popov wrote:

Hi

Alexey Popov wrote:
Now we also have terribly performing PostgreSQL on 8-core server. We 
noticed the slowdown after moving PostgreSQL from 2xXeon 3.0 
Apache+PostgreSQL server to dedicated PostgreSQL server. I collected 
some stats (see attach) before moving to Linux.
Sorry for the broken top ouptut in previuos message. Here's the correct 
one.


last pid: 70857;  load averages: 35.05, 37.11, 33 up 25+23:08:00  12:46:29
94 processes:  46 running, 48 sleeping
CPU: 17.0% user,  0.0% nice, 80.5% system,  0.2% interrupt,  2.3% idle
Mem: 1209M Active, 1890M Inact, 494M Wired, 143M Cache, 214M Buf, 127M Free
Swap: 2048M Total, 72K Used, 2048M Free


Have you tried testing with different values for kern.hz? I am by no 
means an expert, but have stumbled across various postings over the past 
few years that suggest the high value (1000) used by modern (5.x+?) 
kernels can be pessimistic for some workloads...


If you could try testing with some other values by setting in 
/boot/loader.conf, eg:


kern.hz="100"

Perhaps testing 100 and 200 to see how they fare against the default 
value of 1000, would at least provide some indicator as to whether this 
has any bearing on performance.


Some with a better knowledge of the kernel internals may be able to 
support or dimiss this idea, but as Kris is off on holidays I figured 
any suggestion was worthwhile! ;-)


I'd also like to say thanks for your efforts to help test and track down 
the cause of these performance problems - in the end the whole community 
benefits, so the more you are able to test and help resolve these things 
the better for us all... :-)


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

Re: Intel S3000AH stall on boot

[Antony Mawer]

On 3/12/2007 1:37 PM, Tim Daneliuk wrote:

Jack Vogel wrote:

On Dec 1, 2007 8:32 PM, Daniel O'Connor <[EMAIL PROTECTED]> wrote:

Hi,
I am doing some work for a company that recently bought 2 systems based
on the above motherboard and mostly they work fine, however on boot
just before userland starts they stall for about a minute. (Just after
it starts the second CPU).


Did you happen to check if during that time the floppy disk is being 
accessed?

If it is just reconfig the kernel with that device out and the hang
won't happen.

That is the only hang that I've seen that lasts that long.

Jack



Or you can just turn it off in the BIOS to avoid having to fiddle with the
kernel.  *Why* this is happening is of more interest to me.  ISTM that
the kernel startup logic should be able to detect a floppy drive with no
disk in it and move on promptly.  I believe this because that is exactly
what 4.x did ... well, now that I think about it, I never tried 4.x on
the Intel MOBO that is causing this aggravation here


Another "me too". We saw this and wound up removing the floppy drive 
from the systems in order to avoid this lengthy delay on boot - we 
weren't using them anyway and it saved a whole $5 or so on the hardware 
costs... ;-)


I seem to recall it was not purely a 6.x thing - as I'm sure that we 
have plenty of 6.x machines with FDDs that don't exhibit this hang - but 
it was only newer Intel motherboards (I think 9xx series onwards) that 
we were seeing the issue on...


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

swapon running before savecore (was Re: RELENG_6 kernel panic + savecore(8) problem)

[Antony Mawer]

On 26/11/2007 1:33 PM, Jeremy Chadwick wrote:

On Sun, Nov 25, 2007 at 06:21:36PM -0800, Jeremy Chadwick wrote:

I believe the problem is that /etc/rc.d/swap1 is being run before
savecore.  I'm guessing that swapon(8) actually destroys/clobbers the
existing saved kernel panic/core data, thus one will never get a
coredump in /var/crash.  I believe some re-organisation of rcorder(8)
arguments in the files is in order, but I don't know what should
be changed to what.

I'll submit a PR for the above, because IMHO that's a serious one.


PR 118255 has been opened for this matter.

http://www.freebsd.org/cgi/query-pr.cgi?pr=118255


There seems to be conflicting information about what constitutes the 
correct behaviour here. The original 4.4BSD "Unix System Manager's 
Manual (SMM)", found here:


http://docs.freebsd.org/44doc/smm/02.config/paper-6.html

Indicates the following (found under the "System dumps" heading):

- Kernel dumps write from the end of swap and work backwards
- The kernel uses swap from the front and works forward
- This way it reduces the chance of swapping overwriting the dump
   during the boot process until savecore is run

This somewhat more modern posting suggests that is still the case:

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2005-11/0703.html

However the FreeBSD Developers' Handbook suggests a behaviour that does 
not match the current reality:


http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#EXTRACT-DUMP

Can anyone speak with more authority on this...?

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

Re: dd as an imaging solution.

[Antony Mawer]

On 6/02/2007 1:47 PM, Sean Bryant wrote:

Dominic Marks wrote:

Check out G4U (NetBSD based)


The only problem I can see here is that multiple parallel reads will 
have serious performance impacts, thus greatly increasing the cloning of 
the disk.


The solution with dd, tee and netcat would just daisy chain the copy 
across the network which would be way faster.


Now all you need is G4U to operate in a multicast manner like Symantec 
Ghost Corporate Edition, and your transfer speed wouldn't reduce with 
each additional client (eg. 100mbps for 1 client, 50mbps each for 2 
clients, 33.3mbps each for 3 clients, ...)


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

Re: Cached file read performance with 6.2-PRERELEASE

[Antony Mawer]

On 20/12/2006 12:05 PM, Mark Kirkwood wrote:
In the process of investigating performance in another area I happened 
to be measuring sequential cached reads (in a fairly basic manner):


$ dd if=/dev/zero of=/tmp/file bs=8k count=10  # create file
81920 bytes transferred in 4.849394 secs (168928321 bytes/sec)

$ dd of=/dev/null if=/tmp/file bs=8k   # read it
81920 bytes transferred in 2.177922 secs (376138354 bytes/sec)
$ dd of=/dev/null if=/tmp/file bs=8k   # read again
81920 bytes transferred in 2.178407 secs (376054620 bytes/sec)
$ dd of=/dev/null if=/tmp/file bs=32k  # read it
81920 bytes transferred in 1.801944 secs (454620117 bytes/sec)

I ran vmstat to check there really was no read access to the filesystem.

Now I had no idea whether this was the sort of performance to be 
expected or not, so checked on an *identical* cpu, memory, mobo machine 
running Gentoo - this gets 620MB/s for 8k blocks and 700MB/s for 32k ones.


...

The system is 2x1.26Ghz PIII, Supermicro P3TDER Serverworks HE-SL (dual 
channel), 2x1G PC133 ECC DIMMS


What does the memory-related stats from "top" show you? Did you have any 
other memory intensive applications running at the time? A random 
example from one of my systems (1GB RAM):


Mem: 478M Active, 317M Inact, 150M Wired, 36M Cache, 111M Buf, 16M Free

Glancing at the 'top' man page, "150M Wired" seems to be the data file 
cache, while "111M Buf" is block-level caching... and "36M Cache" is 
related to the VM. See the end of this email for the same figures after 
some testing - the "Wired" figure goes up while "Cache" disappears.


That should give you an idea as to how much RAM is being used for the 
buffer/block IO cache ("111M Buf" in the above example, as I understand 
it), and the VM disk cache ("36M Cache" in the above example).


You might also want to look at:

sysctl vfs.

and see whether or not there is anything there that may affect it. For 
instance, whether there is a maximum size in terms of files that will be 
cached...? Someone with more VFS/etc knowledge than I may be able to 
better advise you there...


It might be worthwhile trying with a series of different file size to 
determine if there is a point where the caching performance drops... I 
just did a few quick tests on a relatively old machine (2x P3-933Mhz, 
1GB RAM)... in this case, /tmp is on a 3ware SATA RAID controller 
(8xxx?) running RAID1 on two 160gb SATA disks)...


First, with an 8MB file:

$ dd if=/dev/zero of=/tmp/zero bs=8k count=1000
1000+0 records in
1000+0 records out
8192000 bytes transferred in 0.238275 secs (34380470 bytes/sec)
$ dd if=/tmp/zero of=/dev/null bs=8k
1000+0 records in
1000+0 records out
8192000 bytes transferred in 0.022824 secs (358919664 bytes/sec)
$ dd if=/tmp/zero of=/dev/null bs=8k
1000+0 records in
1000+0 records out
8192000 bytes transferred in 0.022845 secs (358590033 bytes/sec)

Next, with an 80MB file:

$ dd if=/dev/zero of=/tmp/zero bs=8k count=1
1+0 records in
1+0 records out
8192 bytes transferred in 2.549876 secs (32127050 bytes/sec)
$ dd if=/tmp/zero of=/dev/null bs=8k
1+0 records in
1+0 records out
8192 bytes transferred in 0.226559 secs (361583258 bytes/sec)
$ dd if=/tmp/zero of=/dev/null bs=8k
1+0 records in
1+0 records out
8192 bytes transferred in 0.232528 secs (352301702 bytes/sec)

Then with an 800MB file, which based on the results (~360mb/sec down to 
~42mb/sec) presumably blows the cache:


$ dd if=/dev/zero of=/tmp/zero bs=8k count=10
10+0 records in
10+0 records out
81920 bytes transferred in 26.029121 secs (31472442 bytes/sec)
$ dd if=/tmp/zero of=/dev/null bs=8k
10+0 records in
10+0 records out
81920 bytes transferred in 19.463309 secs (42089451 bytes/sec)
$ dd if=/tmp/zero of=/dev/null bs=8k
10+0 records in
10+0 records out
81920 bytes transferred in 19.224657 secs (42611944 bytes/sec)

Trying with something in between, I tried a 200mb file:

$ dd if=/dev/zero of=/tmp/zero bs=8k count=25000
25000+0 records in
25000+0 records out
20480 bytes transferred in 6.517742 secs (31421925 bytes/sec)
$ dd if=/tmp/zero of=/dev/null bs=8k
25000+0 records in
25000+0 records out
20480 bytes transferred in 0.866951 secs (236230194 bytes/sec)
$ dd if=/tmp/zero of=/dev/null bs=8k
25000+0 records in
25000+0 records out
20480 bytes transferred in 0.849929 secs (240961277 bytes/sec)

So here we are somewhere in between -- around 240mb/sec... Looking at 
"top" now, I am seeing:


Mem: 479M Active, 282M Inact, 199M Wired, 111M Buf, 36M Free

compared with the earlier figures:

Mem: 478M Active, 317M Inact, 150M Wired, 36M Cache, 111M Buf, 16M Free

Hopefully all this means something and points you in the right 
direction...!!!


--Antony
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubsc

Re: The need for initialising disks before use?

[Antony Mawer]

On 18/08/2006 4:29 AM, Brooks Davis wrote:

On Fri, Aug 18, 2006 at 09:19:04AM -0500, Kirk Strauser wrote:

On Thursday 17 August 2006 8:35 am, Antony Mawer wrote:


A quick question - is it recommended to initialise disks before using
them to allow the disks to map out any "bad spots" early on?
Note: if you once you actually start seeing bad sectors, the drive is almost 
dead.  A drive can remap a pretty large number internally, but once that 
pool is exhausted (and the number of errors is still growing 
exponentially), there's not a lot of life left.


There are some exceptions to this.  The drive can not remap a sector
which failes to read.  You must perform a write to cause the remap to
occur.  If you get a hard write failure it's gameover, but read failures
aren't necessicary a sign the disk is hopeless.  For example, the drive
I've had in my laptop for most of the last year developed a three sector[0]
error within a week or so of arrival.  After dd'ing zeros over the
problem sectors the problem sectors I've had no problems.


This is what prompted it -- I've been seeing lots of drives that are 
showing up with huge numbers of read errors - for instance:



Aug 19 04:02:27 server kernel: ad0: FAILURE - READ_DMA status=51 
error=40 LBA=66293984
Aug 19 04:02:27 server kernel: g_vfs_done():ad0s1f[READ(offset=30796791808, 
length=16384)]error = 5
Aug 19 04:02:31 server kernel: ad0: FAILURE - READ_DMA status=51 
error=40 LBA=47702304
Aug 19 04:02:31 server kernel: g_vfs_done():ad0s1f[READ(offset=21277851648, 
length=16384)]error = 5
Aug 19 04:02:36 server kernel: ad0: FAILURE - READ_DMA status=51 
error=40 LBA=34943296
Aug 19 04:02:36 server kernel: g_vfs_done():ad0s1f[READ(offset=14745239552, 
length=16384)]error = 5
Aug 19 04:03:08 server kernel: ad0: FAILURE - READ_DMA status=51 
error=40 LBA=45514848
Aug 19 04:03:08 server kernel: g_vfs_done():ad0s1f[READ(offset=20157874176, 
length=16384)]error = 5


I have /var/log/messages flooded with incidents of these "FAILURE - 
READ_DMA" messages. I've seen it on more than one machine with 
relatively "young" drives.


I'm trying to determining of running a dd if=/dev/zero over the whole 
drive prior to use will help reduce the incidence of this, or if it is 
likely that these are developing after the initial install, in which 
case this will make negligible difference...


Once I do start seeing these, is there an easy way to:

a) determine what file/directory entry might be affected?
b) dd if=/dev/zero over the affected sectors only, in order to
 trigger a sector remapping without nuking the whole drive
c) depending on where that sector is allocated, I presume I'm
 either going to end up with:
i) zero'd bytes within a file (how can I tell which?!)
   ii) a destroyed inode
  iii) ???

Any thoughts/comments/etc appreciated...

How do other operating systems handle this - Windows, Linux, Solaris, 
MacOSX ...? I would have hoped this would be a condition the OS would 
make some attempt to trigger a sector remap... or are OSes typically 
ignorant of such things?


Regards
Antony

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

The need for initialising disks before use?

[Antony Mawer]

Hi list,

A quick question - is it recommended to initialise disks before using 
them to allow the disks to map out any "bad spots" early on? I've seen 
some "uninitialised" disks (ie. new disks, thrown into a machine, 
newfs'd) start to show read errors within a few months of deployment, 
which I thought one or two might seem okay, but on a number of machines 
is more than a coincidence...


Is it recommended/required to do something like:

dd if=/dev/zero of=/dev/ad0 bs=1m

before use to ensure the drive's sector remappings are all in place, 
before then doing a newfs?


FWIW, I've been seeing this on more 6.0 systems that I would have 
thought to be just chance...


Cheers
Antony

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

Re: ncplogin panic

[Antony Mawer]

On 9/08/2006 10:01 PM, [EMAIL PROTECTED] wrote:

Antony Mawer <[EMAIL PROTECTED]> schrieb am 09.08.2006 02:08:20:

Okay. What version of Netware are you using? What are the step-by-step
procedures you are following in order to reproduce this (from step 1 as
logging in to Netware or mounting the volume)?



We're using Netware Verion 6.5 over TCP/IP only.

Step 1. load ncp.ko, mount volume (mount_nwfs -A ... )
Step 2. cp /netwarefile /localfolder

Here is what strace gives me:

...

stat("file", {st_mode=S_IFREG|0755, st_size=12, ...}) = 0
stat("/root/file", {st_mode=0, st_size=4294967297, ...}) = 0
open("file", O_RDONLY)  = 3
open("/root/file", O_WRONLY|O_TRUNC)= 4
mmap(0, 12, PROT_READ, MAP_SHARED, 3, 0) = -1 EINVAL (Invalid argument)


Pure speculation -- I wonder if this is because "cp" is trying to mmap 
the file, and for whatever reason that doesn't work as intended with 
NWFS? Could you try using something else - eg. we use rsync against 
Netware friendly with success?


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

Re: ncplogin panic

[Antony Mawer]

On 8/08/2006 5:20 PM, [EMAIL PROTECTED] wrote:

Sory if i forgott that.

I get this when i am copying from the Netware Server. Copying to the Server 
works well.


Okay. What version of Netware are you using? What are the step-by-step 
procedures you are following in order to reproduce this (from step 1 as 
logging in to Netware or mounting the volume)?


I've mounted Netware volumes read-only many times and copied large 
quantities of files from them, generally without problems - except for 
the infamous vanishing "." directory bug.


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

Re: ncplogin panic

[Antony Mawer]

On 7/08/2006 7:40 PM, [EMAIL PROTECTED] wrote:

With this changes (i use Version 1.17 from cvs) i get no more panics.

But i still get some

md_get_mem(461): incomplete copy

messages.

I aslo still got the problem that i can't copy smal files (<8M) with "cp". I get an "invalid 
argument" message from "cp". So "less"
or "cat" can display the smal files without problems.


Are you copying to or from the Netware server?

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

Re: vm_map.c lock up (Was: Re: NFS Locking Issue)

[Antony Mawer]

On 14/07/2006 6:08 PM, User Freebsd wrote:
Just in case, do you use mlocked mappings ? Also, why so huge number 
of crons exist in the system ? The are all forking now. It may be (can 
not say definitely without further investigation) just a fork bomb.


re: crons ... this, I'm not sure of, but my suspicion was that the crons 
weren't able to complete, since the file system was locked up, but the 
next one was being attempted to run ... *shrug*


This seems consistent with behaviour I've seen in on several 6.0-RELEASE 
machines.. from the limited information I've been able to get from the 
machines, there has appeared to be multiple tasks from cron all piled up 
upon one another. In particular, the daily periodic tasks that run the 
various 'find' were one of the things I noticed (although we run 
numerous tasks out of cron)...


If something is blocking the filesystem and causing find (and possibly 
other processes) to become stuck, these would just keep mounting up 
until it all falls over (with numerous maxproc exceeded etc errors).


These are on machines without NFS, but the symptoms are very very 
similar.. NWFS and SMBFS are commonly used on a number of the machines 
I've seen the problem on, which may be relevant -- perhaps it affects 
more than just NFS?


I may experiment with building up a test server locally and trying to 
reproduce similar loads to see if I can trigger the problem in-house.. 
at least that way I can hook up a serial console and get some more 
detailed information...


Regards
Antony

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

Re: long timeout on boot

[Antony Mawer]

On 3/06/2006 2:43 AM, Jack Vogel wrote:

On 6/2/06, Gavin Atkinson <[EMAIL PROTECTED]> wrote:

On Thu, 2006-06-01 at 15:30 -0700, Jack Vogel wrote:
> Both on my own machine, and on systems in our test group's lab, we
> notice these long (like 2min maybe?) delays near the end of boot. It
> seems to be ATA/SATA related. It has just announced the one disk
> it discovered, then shows the CPUs launched, and then it just sits
> printing nothing for, like I said, maybe a minute or two. Finally it 
will

> complete boot and all seems to be fine.

Can you put a verbose dmesg up with debug.fdc.debugflags=255 set from
the loader?

I suspect you'll find it's floppy-related.  Try setting
hint.fdc.0.disabled="1" from the loader and seeing if it goes away.


YUP, I hadnt looked before, but during the whole timeout the floppy
access light is on. There were some messages during boot from the
controller as well.


I've seen this on a number of 6.0 production systems with exactly the 
same symptoms. Disabling the floppy controller removes the long delay.


I've skimmed the change log for the fdc driver:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fdc/

... but there have been a huge number of commits over the recent few 
years. Any number of those sounds like potential candidates for 
introducing the problem, but it will need someone with a large degree of 
patience to try and identify where the problem started occurring.


I might add that it seems very hardware dependent: unfortunately none of 
my test machines on-hand exhibit the problem or I might be able to do 
some testing myself...


-Antony

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

Re: em(4) device still 'freezes' on latset CVSup'd 6.x ...

[Antony Mawer]

On 4/05/2006 6:20 PM, Rutger Bevaart wrote:
Technically it's not routes that are not being updated, but a stale 
(outdated) ARP cache on the other hosts. The system with the new 
alias'ed IP needs to do a gratuitous ARP (broadcast ARP for it's own 
IP). As an intermediate solution you could flush the ARP cache on the 
hosts with stale cache (usually a router or L3 switch on the subnet). 
Sounds like a bug in the em driver. Anybody do sniffing to see if it 
does send out ARPs? If not I can test on one of our Dell 2850's with em's.


If true, this would explain something I've seen this a couple of times 
when an IP address has changed, and the ARP cache on the router had to 
be flushed before the new address was picked up correctly. In all cases 
this was running on machines with em0 (Intel Pro/1000) NICs.


I hadn't thought too much of it at the time as it was not a frequent 
occurrence and thus I put it down to one of those things that "just 
happens".


-Antony

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

Re: IBM LS20 and a 6.1-BETA1 install

[Antony Mawer]

On 20/02/2006 10:18 AM, Damian Gerow wrote:

I've been trying to coax 6.1-BETA1 onto an IBM LS20 Blade (885055U), with a
few problems.  I've turned up a number of other posts about people who have
had the same problem, but nobody seems to be able to get it working.

On boot, the keyboard works in the boot menu (beastie.4th), but once the
kernel probes the hardware, it stops working.  So when the install screen
comes up, there's not a whole lot you can do.

All of the keyboard, mouse, floppy, and CD-ROM are wired into the blade via
USB1.1.  Note that the difference between the LS20 and HS20 is that the L
series are Opteron-based, and the H series are Pentium-based.


This may be something you have already tried, but I mention it just in 
case you have not -- can you boot if you select the "Boot FreeBSD with 
USB keyboard" item from the menu? Or does it not appear (reading the 
beastie.4th, it appears to be i386 only, so if you're using an x86-64 
release then you may not see it)?


All it appears to do is set:

hint.atkbd.0.flags=0x1

so perhaps you can try setting this manually and see if it helps.

-Antony

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

Re: Why use 60 sec on da0 during boot?

[Antony Mawer]

On 20/11/2005 7:32 AM, Lukas Ertl wrote:

It has nothing to do with the SCSI controller, it's all about the
floppy drive.  It seems like the fdc driver doesn't recognize that
there's no disk in the drive and tries to access it on and on and on. 
As I said, disable the floppy drive in the BIOS (or even put a floppy

into the drive), then the boot process goes on as usual.


Indeed - I saw this just the other day on a purely Serial ATA/IDE 
system. Just after detecting the IDE disks, the system paused for about 
60 seconds, with the floppy drive light coming on. After ~60sec it then 
continued without a problem.


Slightly alarming, but apparently harmless...

-Antony

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

Re: FreeBSD6.0 and VMWare 5.0.. No go

[Antony Mawer]

On 1/09/2005 11:15 PM, Edwin Brown wrote:
> This morning I tried to install FreeBSD6.0 under VMWare 5. I got 
> the following message when it was extracting the base into \ 
> directory:
> 
> Panic: duplicate free of item 0xc1c5a210 from zone 0xc143f000(g_bio)
> 
> cpuid=0
> KDB: enter: panic
> [thread pid 3 tid 100034 ]
> stopped at kdb_enter+0x2b: nop
> db> 
> 
> Is this a known issue?

I've seen it reported before, but I don't recall seeing a solution. I
hope this is a show-stopper for 6.0, as a number of places I know of use
VMware for testing and development with FreeBSD...

-Antony

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

4.x smbfs getdirentries() failure - need help debugging

[Antony Mawer]

Hi all,

Have been doing my best to plod through debugging an issue with SMBFS on
FreeBSD 4.11, where with a certain size directory, getdirentries()
returns errno=9 (Bad file descriptor) when it reaches the end of the
directory listing. I've traced it that far and found PR 78953 that
appears to be the same issue, but am a bit out of my depth as to where
to go from here.

http://www.freebsd.org/cgi/query-pr.cgi?pr=78953

Would anyone be able to provide any pointers on where to go from here in
trying to track down the cause? I've provided instructions that reliably
allow me to reproduce the problem with a Windows XP machine as the
source for the smbfs share, if anyone wants to have a look...

At this point I'm guessing I need DDB to figure out what the kernel's
doing and determine exactly where & why this error is arrising.

Any help would be much appreciated, as at this point I'm into the
unchartered (for me) world of the kernel! :-)

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

Re: make release broken (touch: not found)

[Antony Mawer]

Andrew wrote:

Hi,

I am trying to make release for 4.7-RELEASE-p2 and it is failing with
'touch: not found" (errors below). I found someone with a similar problem
in the archives
(http://docs.freebsd.org/cgi/getmsg.cgi?fetch=243803+0+/usr/local/www/db/text/2002/freebsd-stable/20021027.freebsd-stable)
but from the follow up they seem to indicate the problem has gone away but
I am still getting it.

I have to admit I can't even see where touch is called...


Have you done a cd /usr/src && make buildworld first? I ran into this 
about 24hrs ago, as it seems 'make release' expects a 'make buildworld' 
to have been executed prior to execution. It then installs into the 
chroot'd directory and starts its work from there!

-Antony



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: write cache not actually disabled by sysctl?

[Antony Mawer]

I neglected to mention, this is on FreeBSD 4.6 -STABLE as of August 10th.

-Antony

Antony Mawer wrote:
> After reading about the potential dangers assocaited with enabling the 
> write cache on ATA drives in combination with softupdates, I've recently 
> added the following to /boot/loader.conf:
> 
> hw.ata.wc="0"
> 
> Once booted, running sysctl confirms that this is set:
> 
> [root@gibson] ~# sysctl hw.ata.wc
> hw.ata.wc: 0
> 
> However, looking at the atacontrol cap output, it appears that write 
> caching is still enabled on both ATA drives (see below). Can I trust the 
> information from atacontrol cap to be accurate? And if so, why is write 
> caching enabled when the sysctl is explicitly set to off? The system was 
> rebooted after adding the change to loader.conf to allow it to take 
> effect...
> 
> I'm not overly worried by sacrificing some performance for potentially 
> increased safety gains as disabling write caching involves...
> 
> Any thoughts?
> -Antony
> 
> [atacontrol output below]
> 
> 
> 
> [root@gibson] ~# atacontrol cap 2 0
> ATA channel 2, Master, device ad4:
> 
> ATA/ATAPI revision5
> device model  ExcelStor Technology CT210
> firmware revision ES4CA53D
> cylinders 16383
> heads 16
> sectors/track 63
> lba supported 20040450 sectors
> lba48 not supported
> dma supported
> overlap not supported
> 
> Feature  Support  EnableValue   Vendor
> write cacheyes  yes
> read ahead yes  yes
> dma queued no   no  0/00
> SMART  yes  no
> microcode download yes  yes
> security   yes  no
> power management   yes  yes
> advanced power management  no   no  0/00
> automatic acoustic management  no   no  0/000/00
> 
> 
> [root@gibson] ~# atacontrol cap 3 0
> ATA channel 3, Master, device ad6:
> 
> ATA/ATAPI revision5
> device model  QUANTUM FIREBALLlct20 10
> firmware revision APL.0900
> cylinders 16383
> heads 16
> sectors/track 63
> lba supported 20044080 sectors
> lba48 not supported
> dma supported
> overlap not supported
> 
> Feature  Support  EnableValue   Vendor
> write cacheyes  yes
> read ahead yes  yes
> dma queued no   no  0/00
> SMART  yes  no
> microcode download yes  yes
> security   yes  no
> power management   yes  yes
> advanced power management  no   no  0/00
> automatic acoustic management  yes  no  0/000/00
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-stable" in the body of the message



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

write cache not actually disabled by sysctl?

[Antony Mawer]

After reading about the potential dangers assocaited with enabling the 
write cache on ATA drives in combination with softupdates, I've recently 
added the following to /boot/loader.conf:

 hw.ata.wc="0"

Once booted, running sysctl confirms that this is set:

 [root@gibson] ~# sysctl hw.ata.wc
 hw.ata.wc: 0

However, looking at the atacontrol cap output, it appears that write 
caching is still enabled on both ATA drives (see below). Can I trust the 
information from atacontrol cap to be accurate? And if so, why is write 
caching enabled when the sysctl is explicitly set to off? The system was 
rebooted after adding the change to loader.conf to allow it to take 
effect...

I'm not overly worried by sacrificing some performance for potentially 
increased safety gains as disabling write caching involves...

Any thoughts?
-Antony

[atacontrol output below]



[root@gibson] ~# atacontrol cap 2 0
ATA channel 2, Master, device ad4:

ATA/ATAPI revision5
device model  ExcelStor Technology CT210
firmware revision ES4CA53D
cylinders 16383
heads 16
sectors/track 63
lba supported 20040450 sectors
lba48 not supported
dma supported
overlap not supported

Feature  Support  EnableValue   Vendor
write cacheyes  yes
read ahead yes  yes
dma queued no   no  0/00
SMART  yes  no
microcode download yes  yes
security   yes  no
power management   yes  yes
advanced power management  no   no  0/00
automatic acoustic management  no   no  0/000/00


[root@gibson] ~# atacontrol cap 3 0
ATA channel 3, Master, device ad6:

ATA/ATAPI revision5
device model  QUANTUM FIREBALLlct20 10
firmware revision APL.0900
cylinders 16383
heads 16
sectors/track 63
lba supported 20044080 sectors
lba48 not supported
dma supported
overlap not supported

Feature  Support  EnableValue   Vendor
write cacheyes  yes
read ahead yes  yes
dma queued no   no  0/00
SMART  yes  no
microcode download yes  yes
security   yes  no
power management   yes  yes
advanced power management  no   no  0/00
automatic acoustic management  yes  no  0/000/00


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: IDE RAID controlers od FreeBSD

[Antony Mawer]

Mario Pranjic wrote:
> Can anyone tell me if the current 4.6.2 RELEASE supports promise
> fasttrak100tx2 or highpoint hpt370 RAID controlers?
> 
> Does this actually work?

I've got a Promise FastTrak100 TX2 running on -STABLE as of about 2 
weeks ago and FreeBSD picks it up fine. I might add however that I did 
have problems trying to install 4.6-REL onto it on one machine, but 
moving the card to a different machine to install and make world solved 
that hassle.

 From dmesg:

> pci0:  (vendor=0x1106, dev=0x3040) at 7.3
> atapci1:  port 
>0xc800-0xc80f,0xc400-0xc403,0xc000-0xc007,0xbc00-0xbc03,0xb800-0xb807 mem 
>0xed00-0xed00 irq 10 at device 8.0 on pci0
> ata2: at 0xb800 on atapci1
> ata3: at 0xc000 on atapci1
...
> ar0: 9536MB  [1215/255/63] status: READY subdisks:
>  0 READY ad4: 9785MB  [19881/16/63] at ata2-master UDMA66
>  1 READY ad6: 9787MB  [19885/16/63] at ata3-master UDMA100

And once up and running...

[root@gibson] ~# atacontrol status 0
ar0: ATA RAID1 subdisks: ad4 ad6 status: READY

-Antony


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message