freebsd-stable Digest, Vol 252, Issue 10
freebsd-stable@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
or, via email, send a message with subject or body 'help' to
freebsd-stable-request@freebsd.org
You can reach the person managing the list at
freebsd-stable-owner@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-stable digest..."
Today's Topics:
1. Re: g_vfs_done error third part--PLEASE HELP! (Willy Offermans)
2. Re: g_vfs_done error third part--PLEASE HELP! (Jeremy Chadwick)
3. Status of ZFS in -stable? (Pierre-Luc Drouin)
4. Re: g_vfs_done error third part--PLEASE HELP! (Kris Kennaway)
5. Re: Timedia 8 port serial pci card problem (Thomas Vogt)
6. FreeBSD Status Reports for the First Quarter of 2008 (Brad Davis)
7. cfservd crashing on 7.0 (Steve Wills)
8. Re: FreeBSD 7.0-STABLE: "mount_nfs" vs "mount -t nfs":
problems with second one, UDP timeouts and ICMP ports unreach?!
(Lev Serebryakov)
9. RE: cvsup.uk.FreeBSD.org (Tony Finch)
10. Re: how much memory does increasing max rules for IPFW take
up? (Vivek Khera)
11. Re: today's build is causing errors for me (Pollywog)
12. Re: today's build is causing errors for me (Pollywog)
13. Re: FreeBSD 7.0-STABLE: "mount_nfs" vs "mount -t nfs":
problems with second one, UDP timeouts and ICMP ports unreach?!
(Lev Serebryakov)
14. Re: g_vfs_done error third part--PLEASE HELP! (Willy Offermans)
15. Re: g_vfs_done error third part--PLEASE HELP! (Willy Offermans)
16. Re: g_vfs_done error third part--PLEASE HELP! (Jeremy Chadwick)
17. udf (Zoran Kolic)
18. Re: udf (Stefan Lambrev)
19. Re: udf (Jeremy Chadwick)
20. Re: Hard(?) lock when reassociating ath with wpa_supplicant
on RELENG_7 (Sam Leffler)
21. Re: udf (Scott Long)
22. Re: Approaching the limit on PV entries, consider increasing
either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max
sysctl. (Thomas Hurst)
23. Re: Approaching the limit on PV entries, consider increasing
either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max
sysctl. (Evren Yurtesen)
24. Re: g_vfs_done error third part--PLEASE HELP! (Roland Smith)
25. Re: FreeBSD 7.0-STABLE: "mount_nfs" vs "mount -t nfs":
problems with second one, UDP timeouts and ICMP ports unreach?!
(Lev Serebryakov)
26. Re: Approaching the limit on PV entries, consider increasing
either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max
sysctl. (Thomas Hurst)
27. Re: ciss(4) not coping with large arrays? (Emil Mikulic)
28. Re: g_vfs_done error third part--PLEASE HELP! (Willy Offermans)
----------------------------------------------------------------------
Message: 1
Date: Fri, 16 May 2008 14:14:14 +0200
From: Willy Offermans <Willy@Offermans.Rompen.nl>
Subject: Re: g_vfs_done error third part--PLEASE HELP!
To: Roland Smith <rsmith@xs4all.nl>
Cc: freebsd-stable@FreeBSD.ORG
Message-ID: <20080516121414.GD4618@wiz.vpn.offrom.nl>
Content-Type: text/plain; charset=us-ascii
Hello Roland and FreeBSD friends,
I'm sorry to be so quite for a while, but I went away for a vacation.
But now I'm back, I like to solve this issue.
On Mon, Apr 21, 2008 at 10:10:47PM +0200, Roland Smith wrote:
> On Mon, Apr 21, 2008 at 09:04:03PM +0200, Willy Offermans wrote:
> > Dear FreeBSD friends,
> >
> > It is already the third time that I report this error. Can someone help
> > me in solving this issue?
>
> Probably the reason that you hear so little is that you provide so
> little information. Most of us are not clairvoyant.
>
> > Over and over again and always after heavy disk I/O I see the following
> > errors in the log files. If I force ar0s1g to unmount the machine
> > spontaneously reboots. Nothing seriously seems to be damaged by this
> > act, but anyway I cannot afford something bad happening to this
> > production machine.
>
> Why would you force an unmount?
Otherwise the device keeps on reporting to be unavailable and cannot be
unmounted:
sun# umount /share/
umount: unmount of /share failed: Resource temporarily unavailable
>
> > Apr 18 20:02:19 sun kernel: g_vfs_done():ar0s1g[WRITE(offset=290725068800, length=4096)]error = 5
> >
> > I have no clue what the errors mean, since offsets of 290725068800,
> > 290725072896, and 290725074944 seem to be ridiculous. Does anybody
> > have a clue what is going on?
>
> For starters, how big is ar0s1g? If the offset is in bytes, it is around
> 270 GB, which is not that unusual in this day and age.
I have to admit that I was a bit confused by an offset value of
290725068800. There is no indication of a unit, so I assumed that it
was sector but probably it is simply bytes and then indeed the number
does make sense.
>
> > I'm using FreeBSD 7.0, but found the error being reported before with
> > previous versions of FreeBSD. I can and will provide more details on
> > demand.
>
> What does 'df' say?
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ar0s1a 20308398 230438 18453290 1% /
devfs 1 1 0 100% /dev
/dev/ar0s1d 21321454 3814482 15801256 19% /usr
/dev/ar0s1e 50777034 5331686 41383186 11% /var
/dev/ar0s1f 101554150 18813760 74616058 20% /home
/dev/ar0s1g 274977824 34564876 218414724 14% /share
pretty normal I would say.
>
> Did you notice any file corruption in the filesystem on ar0s1g?
No the two disks are brand new and I did not encounter any noticeable
file corruption. However I assume that nowadays bad sectors on HD are
handled by the hardware and do not need any user interaction to correct
this. But maybe I'm totally wrong.
>
> Unmount the filesystem and run fsck(8) on it. Does it report any errors?
sun# fsck /dev/ar0s1g
** /dev/ar0s1g
** Last Mounted on /share
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=34788357 (272 should be 264)
CORRECT? [yn] y
INCORRECT BLOCK COUNT I=34789217 (296 should be 288)
CORRECT? [yn] y
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? [yn] y
SUMMARY INFORMATION BAD
SALVAGE? [yn] y
BLK(S) MISSING IN BIT MAPS
SALVAGE? [yn] y
182863 files, 17282440 used, 120206472 free (12448 frags, 15024253
blocks, 0.0% fragmentation)
***** FILE SYSTEM MARKED CLEAN *****
***** FILE SYSTEM WAS MODIFIED *****
The usual stuff I would say.
>
> > Any hints are very much appreciated.
>
> Did you manage to create a partition larger than the disk is (using
> newfs's -s switch)? In that case it could be that you're trying to write
> past the end of the device.
No, look to the following output:
sun# bsdlabel -A /dev/ar0s1
# /dev/ar0s1:
type: unknown
disk: amnesiac
label:
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 60799
sectors/unit: 976751937
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # milliseconds
track-to-track seek: 0 # milliseconds
drivedata: 0
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 41943040 0 4.2BSD 0 0 0
b: 8388608 41943040 swap
c: 976751937 0 unused 0 0 # "raw"
part, don't edit
d: 44040192 50331648 4.2BSD 2048 16384 28552
e: 104857600 94371840 4.2BSD 2048 16384 28552
f: 209715200 199229440 4.2BSD 2048 16384 28552
g: 567807297 408944640 4.2BSD 2048 16384 28552
/dev/ar0s1g starts after 408944640*512/1024/1024=199680MB
So I have to conclude that the write error message does make sense and
that something seems to be wrong with the disks. The next question is
what can I do about it? Should I return the disks to the shop and ask
for new ones?
However other people that I have contacted and who had a similar
problem before have solved it by using software raid setup instead of a
hardware raid setup. This seems to indicate that there is some bug in
the FreeBSD code.
Another peculiarity that I have to mention is the following. If I use
sysinstall and if I try to ``Label allocated disk partitions'', I
cannot see the partitions on ar0. However the partitions can be
visualised by bsdlabel as shown above.
What is going on and what should I do?
>
> Roland
> --
> R.F.Smith
http://www.xs4all.nl/~rsmith/
> [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
> pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
--
Met vriendelijke groeten,
With kind regards,
Mit freundlichen Gruessen,
De jrus wah,
Willy
*************************************
W.K. Offermans
Home: +31 45 544 49 44
Mobile: +31 653 27 16 23
e-mail: Willy@Offermans.Rompen.nl
Powered by ....
(__)
\\\'',)
\/ \ ^
.\._/_)
------------------------------
Message: 2
Date: Fri, 16 May 2008 05:27:59 -0700
From: Jeremy Chadwick <koitsu@FreeBSD.org>
Subject: Re: g_vfs_done error third part--PLEASE HELP!
To: Willy Offermans <Willy@Offermans.Rompen.nl>
Cc: Roland Smith <rsmith@xs4all.nl>, freebsd-stable@FreeBSD.ORG
Message-ID: <20080516122759.GA61346@eos.sc1.parodius.com>
Content-Type: text/plain; charset=us-ascii
On Fri, May 16, 2008 at 02:14:14PM +0200, Willy Offermans wrote:
> On Mon, Apr 21, 2008 at 10:10:47PM +0200, Roland Smith wrote:
> > Did you notice any file corruption in the filesystem on ar0s1g?
>
> No the two disks are brand new and I did not encounter any noticeable
> file corruption. However I assume that nowadays bad sectors on HD are
> handled by the hardware and do not need any user interaction to correct
> this. But maybe I'm totally wrong.
You're right, but it depends on the type of disk. SCSI disks will
report bad blocks to the OS regardless if it is about to mark the block
as a grown defect or not. PATA and SATA disks, on the other hand, will
report bad blocks to the OS only if the internal bad block list (which
it manages itself -- this is what you're thinking of) is full.
There are still many conditions where PATA and SATA disks can induce
errors in the OS. If the disk is attempting to work around a bad block,
and there's a physical error (servo problem, head crash, repetitive
re-reads of the block due to dust, whatever -- something that "ties up"
the disk for long periods of time), ATA subsystem timeouts may be seen,
DMA errors, or whatever else. SMART stats will show this kind of
problem.
> > Unmount the filesystem and run fsck(8) on it. Does it report any errors?
>
> sun# fsck /dev/ar0s1g
> ** /dev/ar0s1g
> ** Last Mounted on /share
> ** Phase 1 - Check Blocks and Sizes
> INCORRECT BLOCK COUNT I=34788357 (272 should be 264)
> CORRECT? [yn] y
>
> INCORRECT BLOCK COUNT I=34789217 (296 should be 288)
> CORRECT? [yn] y
>
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
> FREE BLK COUNT(S) WRONG IN SUPERBLK
> SALVAGE? [yn] y
>
> SUMMARY INFORMATION BAD
> SALVAGE? [yn] y
>
> BLK(S) MISSING IN BIT MAPS
> SALVAGE? [yn] y
>
> 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253
> blocks, 0.0% fragmentation)
>
> ***** FILE SYSTEM MARKED CLEAN *****
>
> ***** FILE SYSTEM WAS MODIFIED *****
>
> The usual stuff I would say.
How is this usual?. It appears to me you did have some filesystem
corruption.
--
| Jeremy Chadwick jdc 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 |
------------------------------
Message: 3
Date: Tue, 13 May 2008 00:23:12 -0400
From: Pierre-Luc Drouin <pldrouin@pldrouin.net>
Subject: Status of ZFS in -stable?
To: freebsd-stable@freebsd.org
Message-ID: <482917B0.9040302@pldrouin.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
I would like to know memory allocation problem eith zfs has been fixed
in -stable since the release of 7.0? Is zfs more "stable
------------------------------
Message: 4
Date: Fri, 16 May 2008 14:43:24 +0200
From: Kris Kennaway <kris@FreeBSD.org>
Subject: Re: g_vfs_done error third part--PLEASE HELP!
To: Willy@Offermans.Rompen.nl
Cc: Roland Smith <rsmith@xs4all.nl>, freebsd-stable@FreeBSD.ORG
Message-ID: <482D816C.4060402@FreeBSD.org>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Willy Offermans wrote:
> Hello Roland and FreeBSD friends,
>
> I'm sorry to be so quite for a while, but I went away for a vacation.
> But now I'm back, I like to solve this issue.
>
>
> On Mon, Apr 21, 2008 at 10:10:47PM +0200, Roland Smith wrote:
>> On Mon, Apr 21, 2008 at 09:04:03PM +0200, Willy Offermans wrote:
>>> Dear FreeBSD friends,
>>>
>>> It is already the third time that I report this error. Can someone help
>>> me in solving this issue?
>> Probably the reason that you hear so little is that you provide so
>> little information. Most of us are not clairvoyant.
>>
>>> Over and over again and always after heavy disk I/O I see the following
>>> errors in the log files. If I force ar0s1g to unmount the machine
>>> spontaneously reboots. Nothing seriously seems to be damaged by this
>>> act, but anyway I cannot afford something bad happening to this
>>> production machine.
>> Why would you force an unmount?
>
> Otherwise the device keeps on reporting to be unavailable and cannot be
> unmounted:
>
> sun# umount /share/
> umount: unmount of /share failed: Resource temporarily unavailable
>
>>> Apr 18 20:02:19 sun kernel: g_vfs_done():ar0s1g[WRITE(offset=290725068800, length=4096)]error = 5
>>>
>>> I have no clue what the errors mean, since offsets of 290725068800,
>>> 290725072896, and 290725074944 seem to be ridiculous. Does anybody
>>> have a clue what is going on?
>> For starters, how big is ar0s1g? If the offset is in bytes, it is around
>> 270 GB, which is not that unusual in this day and age.
>
> I have to admit that I was a bit confused by an offset value of
> 290725068800. There is no indication of a unit, so I assumed that it
> was sector but probably it is simply bytes and then indeed the number
> does make sense.
>>> I'm using FreeBSD 7.0, but found the error being reported before with
>>> previous versions of FreeBSD. I can and will provide more details on
>>> demand.
>> What does 'df' say?
>
> Filesystem 1K-blocks Used Avail Capacity Mounted on
> /dev/ar0s1a 20308398 230438 18453290 1% /
> devfs 1 1 0 100% /dev
> /dev/ar0s1d 21321454 3814482 15801256 19% /usr
> /dev/ar0s1e 50777034 5331686 41383186 11% /var
> /dev/ar0s1f 101554150 18813760 74616058 20% /home
> /dev/ar0s1g 274977824 34564876 218414724 14% /share
>
> pretty normal I would say.
>
>> Did you notice any file corruption in the filesystem on ar0s1g?
>
> No the two disks are brand new and I did not encounter any noticeable
> file corruption. However I assume that nowadays bad sectors on HD are
> handled by the hardware and do not need any user interaction to correct
> this. But maybe I'm totally wrong.
>
>> Unmount the filesystem and run fsck(8) on it. Does it report any errors?
>
> sun# fsck /dev/ar0s1g
> ** /dev/ar0s1g
> ** Last Mounted on /share
> ** Phase 1 - Check Blocks and Sizes
> INCORRECT BLOCK COUNT I=34788357 (272 should be 264)
> CORRECT? [yn] y
>
> INCORRECT BLOCK COUNT I=34789217 (296 should be 288)
> CORRECT? [yn] y
>
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
> FREE BLK COUNT(S) WRONG IN SUPERBLK
> SALVAGE? [yn] y
>
> SUMMARY INFORMATION BAD
> SALVAGE? [yn] y
>
> BLK(S) MISSING IN BIT MAPS
> SALVAGE? [yn] y
>
> 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253
> blocks, 0.0% fragmentation)
>
> ***** FILE SYSTEM MARKED CLEAN *****
>
> ***** FILE SYSTEM WAS MODIFIED *****
>
> The usual stuff I would say.
No, any form of filesystem corruption is not usual.
>
>>> Any hints are very much appreciated.
>> Did you manage to create a partition larger than the disk is (using
>> newfs's -s switch)? In that case it could be that you're trying to write
>> past the end of the device.
>
> No, look to the following output:
>
> sun# bsdlabel -A /dev/ar0s1
> # /dev/ar0s1:
> type: unknown
> disk: amnesiac
> label:
> flags:
> bytes/sector: 512
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 60799
> sectors/unit: 976751937
> rpm: 3600
> interleave: 1
> trackskew: 0
> cylinderskew: 0
> headswitch: 0 # milliseconds
> track-to-track seek: 0 # milliseconds
> drivedata: 0
>
> 8 partitions:
> # size offset fstype [fsize bsize bps/cpg]
> a: 41943040 0 4.2BSD 0 0 0
> b: 8388608 41943040 swap
> c: 976751937 0 unused 0 0 # "raw"
> part, don't edit
> d: 44040192 50331648 4.2BSD 2048 16384 28552
> e: 104857600 94371840 4.2BSD 2048 16384 28552
> f: 209715200 199229440 4.2BSD 2048 16384 28552
> g: 567807297 408944640 4.2BSD 2048 16384 28552
>
> /dev/ar0s1g starts after 408944640*512/1024/1024=199680MB
>
>
> So I have to conclude that the write error message does make sense and
> that something seems to be wrong with the disks. The next question is
> what can I do about it? Should I return the disks to the shop and ask
> for new ones?
#define EIO 5 /* Input/output error */
At least one of your disks is toast.
Kris
------------------------------
Message: 5
Date: Fri, 16 May 2008 15:36:25 +0200
From: Thomas Vogt <freebsdlists@bsdunix.ch>
Subject: Re: Timedia 8 port serial pci card problem
To: Marcel Moolenaar <xcllnt@mac.com>
Cc: freebsd-stable@freebsd.org
Message-ID: <81B25D8A-5EE6-4C18-A170-15ADACA8B3C7@bsdunix.ch>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Hi Marcel
Am 16.05.2008 um 12:53 schrieb Marcel Moolenaar:
>
> On May 16, 2008, at 1:17 AM, Thomas Vogt wrote:
>
>> FreeBSD detects it with: "puc0: <Timedia technology 8 Port Serial>
>> port 0xe500-0xe51f,0xe520-0xe52f,0xe530-0xe537,0xe538-0xe53f,
>> 0xe540-0xe547,0xe548-0xe54f irq 10 at device 14.0 on pci0" . But it
>> only adds 3 uart ports instead of 8. Any idea what i can do?
>
> Can you try the following (white-space corrupted) patch:
>
> Index: pucdata.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/dev/puc/pucdata.c,v
> retrieving revision 1.59.2.1
> diff -u -r1.59.2.1 pucdata.c
> --- pucdata.c 26 Feb 2008 09:33:57 -0000 1.59.2.1
> +++ pucdata.c 16 May 2008 10:48:25 -0000
> @@ -1116,7 +1116,7 @@
> *res = (port == 1 || port == 3) ? 8 : 0;
> return (0);
> case PUC_CFG_GET_RID:
> - *res = 0x10 + ((port > 3) ? port - 2 : port >> 1);
> + *res = 0x10 + ((port > 3) ? port - 2 : port >> 1) * 4;
> return (0);
> case PUC_CFG_GET_TYPE:
> *res = PUC_TYPE_SERIAL;
Thats it. It works with your patch
dmesg:
puc0: <Timedia technology 8 Port Serial> port 0xe500-0xe51f,
0xe520-0xe52f,0xe530-0xe537,0xe538-0xe53f,0xe540-0xe547,0xe548-0xe54f
irq 10 at device 14.0 on pci0
puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xe500
puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe520
puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe530
puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe538
puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe540
puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe548
puc0: [FILTER]
uart0: <Non-standard ns8250 class UART with FIFOs> on puc0
uart0: [FILTER]
uart0: fast interrupt
uart1: <Non-standard ns8250 class UART with FIFOs> on puc0
uart1: [FILTER]
uart1: fast interrupt
uart2: <Non-standard ns8250 class UART with FIFOs> on puc0
uart2: [FILTER]
uart2: fast interrupt
uart3: <Non-standard ns8250 class UART with FIFOs> on puc0
uart3: [FILTER]
uart3: fast interrupt
uart4: <Non-standard ns8250 class UART with FIFOs> on puc0
uart4: [FILTER]
uart4: fast interrupt
uart5: <Non-standard ns8250 class UART with FIFOs> on puc0
uart5: [FILTER]
uart5: fast interrupt
uart6: <Non-standard ns8250 class UART with FIFOs> on puc0
uart6: [FILTER]
uart6: fast interrupt
uart7: <Non-standard ns8250 class UART with FIFOs> on puc0
uart7: [FILTER]
uart7: fast interrupt
Thank you,
Thomas
------------------------------
Message: 6
Date: Fri, 16 May 2008 07:43:46 -0600
From: Brad Davis <brd@FreeBSD.org>
Subject: FreeBSD Status Reports for the First Quarter of 2008
To: hackers@FreeBSD.org
Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org
Message-ID: <20080516134346.GB1844@valentine.liquidneon.com>
Content-Type: text/plain; charset=us-ascii
Hi Everyone,
The FreeBSD Status Reports for the First Quarter of 2008 are now
available at:
http://www.freebsd.org/news/status/report-2008-01-2008-03.html
Regards,
Brad Davis
------------------------------
Message: 7
Date: Fri, 16 May 2008 09:42:35 -0400
From: Steve Wills <steve@mouf.net>
Subject: cfservd crashing on 7.0
To: stable@freebsd.org
Message-ID: <9A673D2F-8758-44D9-A41A-382610B377BA@mouf.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Hi,
I just moved my cfservd (a part of sysutils/cfengine) from a 6.2
server to a 7.0 server. Ever since, cfservd crashes regularly. The
backtrace is below, although obviously it is missing a lot. If anyone
has clues or suggestions, I'd really appreciate it.
# gdb /usr/local/sbin/cfservd cfservd.core
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"...(no debugging
symbols found)...
Core was generated by `cfservd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libdb-4.6.so.0...(no debugging
symbols found)...done.
Loaded symbols for /usr/local/lib/libdb-4.6.so.0
Reading symbols from /lib/libthr.so.3...(no debugging symbols
found)...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libcrypto.so.5...(no debugging symbols
found)...done.
Loaded symbols for /lib/libcrypto.so.5
Reading symbols from /usr/lib/librt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /lib/libm.so.5...(no debugging symbols
found)...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libc.so.7...(no debugging symbols
found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols
found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x283214e0 in sha1_block_data_order () from /lib/libcrypto.so.5
[New Thread 0x28501600 (LWP 100725)]
[New Thread 0x28501500 (LWP 100723)]
[New Thread 0x28501c00 (LWP 100289)]
[New Thread 0x28501a00 (LWP 100722)]
[New Thread 0x28501900 (LWP 100505)]
[New Thread 0x28501400 (LWP 100726)]
[New Thread 0x28501100 (LWP 100614)]
(gdb) bt
#0 0x283214e0 in sha1_block_data_order () from /lib/libcrypto.so.5
#1 0x28323112 in SHA1_Update () from /lib/libcrypto.so.5
#2 0x283114fe in EVP_sha512 () from /lib/libcrypto.so.5
#3 0x2952e080 in ?? ()
#4 0x28391cf4 in ?? () from /lib/libcrypto.so.5
#5 0xffffff6b in ?? ()
#6 0x28311b65 in EVP_DigestInit_ex () from /lib/libcrypto.so.5
#7 0x2831161f in EVP_DigestUpdate () from /lib/libcrypto.so.5
#8 0x282f38ef in RAND_SSLeay () from /lib/libcrypto.so.5
#9 0xbf8f5d20 in ?? ()
#10 0x28391cf4 in ?? () from /lib/libcrypto.so.5
#11 0xffffff6b in ?? ()
#12 0x000001c2 in ?? ()
#13 0x00000100 in ?? ()
#14 0xbf8f5d38 in ?? ()
#15 0x2836aad0 in RSA_version () from /lib/libcrypto.so.5
#16 0xbf8f5d0c in ?? ()
#17 0xbf8f5d30 in ?? ()
#18 0x0000000a in ?? ()
#19 0x000003ff in ?? ()
#20 0x00000001 in ?? ()
#21 0xfffffc0b in ?? ()
#22 0x9479e4c0 in ?? ()
#23 0x907484c9 in ?? ()
---Type <return> to continue, or q <return> to quit---
#24 0x99437746 in ?? ()
#25 0xde61d2b4 in ?? ()
#26 0xaab0b47e in ?? ()
#27 0x2838cc20 in ASN1_OCTET_STRING_NDEF_it () from /lib/libcrypto.so.5
#28 0x00000000 in ?? ()
#29 0x00000000 in ?? ()
#30 0x2952e080 in ?? ()
#31 0x0000952a in ?? ()
#32 0x000036ea in ?? ()
#33 0x00000000 in ?? ()
#34 0x2838f08c in ?? () from /lib/libcrypto.so.5
#35 0x29512080 in ?? ()
#36 0x2952a102 in ?? ()
#37 0xbf8f5d68 in ?? ()
#38 0x282f2eac in RAND_bytes () from /lib/libcrypto.so.5
Previous frame identical to this frame (corrupt stack?)
(gdb)
Thanks,
Steve
------------------------------
Message: 8
Date: Fri, 16 May 2008 17:57:40 +0400
From: Lev Serebryakov <lev@FreeBSD.org>
Subject: Re: FreeBSD 7.0-STABLE: "mount_nfs" vs "mount -t nfs":
problems with second one, UDP timeouts and ICMP ports unreach?!
To: freebsd-stable@freebsd.org
Message-ID: <482D92D4.20908@FreeBSD.org>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Lev Serebryakov wrote:
> You see? b answer with "UDP port unreachable" on each RPC reply!
Additional info.
ktrace from "mount -t nfs":
=============================================================
65962 mount_nfs 0.006679 RET sendto 40/0x28
65962 mount_nfs 0.006682 CALL
kevent(0x4,0x638110,0x1,0x7fffffffe2d0,0x1,0x7fffffffe310)
65962 mount_nfs 10.218001 GIO fd 4 wrote 32 bytes
65962 mount_nfs 10.218018 GIO fd 4 read 0 bytes
""
65962 mount_nfs 10.218023 RET kevent 0
65962 mount_nfs 10.218029 CALL gettimeofday(0x7fffffffe320,0)
65962 mount_nfs 10.218035 RET gettimeofday 0
65962 mount_nfs 10.218040 CALL close(0x4)
65962 mount_nfs 10.218049 RET close 0
65962 mount_nfs 10.218077 CALL close(0x3)
65962 mount_nfs 10.218087 RET close 0
65962 mount_nfs 10.218101 CALL write(0x2,0x7fffffffdd40,0x37)
65962 mount_nfs 10.218117 GIO fd 2 wrote 55 bytes
"[udp] gateway:/usr/ports: NFSPROC_NULL: RPC: Timed out
"
=============================================================
ktrace (same piece) from "mount_nfs":
=============================================================
93109 mount_nfs 0.005458 RET sendto 40/0x28
93109 mount_nfs 0.005462 CALL
kevent(0x4,0x638110,0x1,0x7fffffffe2a0,0x1,0x7fffffffe2e0)
93109 mount_nfs 0.005724 GIO fd 4 wrote 32 bytes
93109 mount_nfs 0.005738 GIO fd 4 read 32 bytes
93109 mount_nfs 0.005743 RET kevent 1
93109 mount_nfs 0.005748 CALL recvfrom(0x3,0x638134,0x2260,0,0,0)
93109 mount_nfs 0.005756 GIO fd 3 read 24 bytes
93109 mount_nfs 0.005761 RET recvfrom 24/0x18
93109 mount_nfs 0.005767 CALL close(0x4)
93109 mount_nfs 0.005775 RET close 0
93109 mount_nfs 0.005781 CALL close(0x3)
93109 mount_nfs 0.005788 RET close 0
=============================================================
------------------------------
Message: 9
Date: Fri, 16 May 2008 15:26:25 +0100
From: Tony Finch <dot@dotat.at>
Subject: RE: cvsup.uk.FreeBSD.org
To: Dr Josef Karthauser <joe@tao.org.uk>
Cc: freebsd-hubs@freebsd.org, freebsd-stable@freebsd.org
Message-ID:
<alpine.LSU.1.00.0805161512400.8138@hermes-1.csi.cam.ac.uk>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 16 May 2008, Dr Josef Karthauser wrote:
>
> As a matter of interest, do you know what the peak bandwidth usage is?
Based on the cvsupd log the peak is around 600KB/sec in and 360KB/sec out
at about 2am. The university's bandwidth accounting system says:
date host in (MB) out (MB) total
2008-05-09 131.111.008.041 1902.863 2890.291 4793.155
2008-05-10 131.111.008.041 9278.231 5287.797 14566.028
2008-05-11 131.111.008.041 9214.064 4059.799 13273.863
2008-05-12 131.111.008.041 9248.677 4458.978 13707.655
2008-05-13 131.111.008.041 8818.575 4651.896 13470.471
2008-05-14 131.111.008.041 9254.688 5833.494 15088.182
2008-05-15 131.111.008.041 9116.638 4715.182 13831.820
Tony.
--
f.anthony.n.finch <dot@dotat.at>
http://dotat.at/
VIKING: NORTHERLY 4 OR 5 INCREASING 6 OR 7, PERHAPS GALE 8 LATER. MODERATE
BECOMING ROUGH. SHOWERS. MODERATE OR GOOD.
------------------------------
Message: 10
Date: Fri, 16 May 2008 10:53:07 -0400
From: Vivek Khera <vivek@khera.org>
Subject: Re: how much memory does increasing max rules for IPFW take
up?
To: FreeBSD Stable <freebsd-stable@freebsd.org>
Cc: freebsd-ipfw@freebsd.org
Message-ID: <BC5FAC20-572B-4D50-92A3-609B3C398712@khera.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
How are the buckets used? Are they hashed per rule number or some
other mechanism? Nearly all of my states are from the same rule (eg,
on a mail server for the SMTP port rule).
How should I scale the buckets with the max rules? The default seems
to be 4096 rules and 256 buckets. Should I maintain that ratio?
------------------------------
Message: 11
Date: Fri, 16 May 2008 14:42:49 +0000
From: Pollywog <lists-fbsdstable@shadypond.com>
Subject: Re: today's build is causing errors for me
To: freebsd-stable@freebsd.org
Message-ID: <200805161442.51667.lists-fbsdstable@shadypond.com>
Content-Type: text/plain; charset="iso-8859-1"
On Friday 16 May 2008 06:17:24 Jeremy Chadwick wrote:
>
> Additionally, mergemaster isn't a confusing mess. If anything, it's one
> of the most simple tools there is for managing /etc. The part you
> probably find "confusing", which is the same part I did when I started
> using it, is the side-by-side interactive diff. It's very easy to use;
> "r" means use the text shown on the right, and "l" means use the text
> shown on the left.
That is certainly the part that confused me until I referred to the "Absolute
FreeBSD" book.
------------------------------
Message: 12
Date: Fri, 16 May 2008 14:41:22 +0000
From: Pollywog <lists-fbsdstable@shadypond.com>
Subject: Re: today's build is causing errors for me
To: freebsd-stable@freebsd.org
Message-ID: <200805161441.24237.lists-fbsdstable@shadypond.com>
Content-Type: text/plain; charset="iso-8859-1"
On Friday 16 May 2008 06:04:34 Rob Lytle wrote:
> Hi Jeremy,
>
> I used Mergemaster. Thats what I mean't when I said that I carefully
> "merged" /usr/src/etc/ with /etc. But like I said, no files were
> replaced that contained my own configuration, e.g. group. I will say
> this- that I have always considered Mergemaster a confusing mess,
> despite the dogma on the lists. I have been running FreeBSD and
> installing it since 1998, so I have some experience- but this is new
> behavior beyond my previous experiences.
I have only been using FreeBSD for almost one year and I am still a little
confused by Mergemaster, but what helped me with it was the book "Absolute
FreeBSD". I would not have been able to deal with it without the book.
------------------------------
Message: 13
Date: Fri, 16 May 2008 19:22:13 +0400
From: Lev Serebryakov <lev@FreeBSD.org>
Subject: Re: FreeBSD 7.0-STABLE: "mount_nfs" vs "mount -t nfs":
problems with second one, UDP timeouts and ICMP ports unreach?!
To: freebsd-stable@freebsd.org
Message-ID: <482DA6A5.4060103@FreeBSD.org>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Lev Serebryakov wrote:
> Main problem is, that "/etc/fstab" is processed by mount, and NFS
> mount hangs up on boot, as shown above :(
Mounting with "mount -t nfs" with 7.0 server (host B) and 6.3 client
(host A) works...
--
// Lev Serebryakov
------------------------------
Message: 14
Date: Fri, 16 May 2008 17:37:56 +0200
From: Willy Offermans <Willy@Offermans.Rompen.nl>
Subject: Re: g_vfs_done error third part--PLEASE HELP!
To: Jeremy Chadwick <koitsu@FreeBSD.org>
Cc: freebsd-stable@FreeBSD.org
Message-ID: <20080516153755.GA9388@wiz.vpn.offrom.nl>
Content-Type: text/plain; charset=us-ascii
Hello Jeremy and FreeBSD friends,
On Fri, May 16, 2008 at 05:27:59AM -0700, Jeremy Chadwick wrote:
> On Fri, May 16, 2008 at 02:14:14PM +0200, Willy Offermans wrote:
> > On Mon, Apr 21, 2008 at 10:10:47PM +0200, Roland Smith wrote:
> > > Did you notice any file corruption in the filesystem on ar0s1g?
> >
> > No the two disks are brand new and I did not encounter any noticeable
> > file corruption. However I assume that nowadays bad sectors on HD are
> > handled by the hardware and do not need any user interaction to correct
> > this. But maybe I'm totally wrong.
>
> You're right, but it depends on the type of disk. SCSI disks will
> report bad blocks to the OS regardless if it is about to mark the block
> as a grown defect or not. PATA and SATA disks, on the other hand, will
> report bad blocks to the OS only if the internal bad block list (which
> it manages itself -- this is what you're thinking of) is full.
>
> There are still many conditions where PATA and SATA disks can induce
> errors in the OS. If the disk is attempting to work around a bad block,
> and there's a physical error (servo problem, head crash, repetitive
> re-reads of the block due to dust, whatever -- something that "ties up"
> the disk for long periods of time), ATA subsystem timeouts may be seen,
> DMA errors, or whatever else. SMART stats will show this kind of
> problem.
>
> > > Unmount the filesystem and run fsck(8) on it. Does it report any errors?
> >
> > sun# fsck /dev/ar0s1g
> > ** /dev/ar0s1g
> > ** Last Mounted on /share
> > ** Phase 1 - Check Blocks and Sizes
> > INCORRECT BLOCK COUNT I=34788357 (272 should be 264)
> > CORRECT? [yn] y
> >
> > INCORRECT BLOCK COUNT I=34789217 (296 should be 288)
> > CORRECT? [yn] y
> >
> > ** Phase 2 - Check Pathnames
> > ** Phase 3 - Check Connectivity
> > ** Phase 4 - Check Reference Counts
> > ** Phase 5 - Check Cyl groups
> > FREE BLK COUNT(S) WRONG IN SUPERBLK
> > SALVAGE? [yn] y
> >
> > SUMMARY INFORMATION BAD
> > SALVAGE? [yn] y
> >
> > BLK(S) MISSING IN BIT MAPS
> > SALVAGE? [yn] y
> >
> > 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253
> > blocks, 0.0% fragmentation)
> >
> > ***** FILE SYSTEM MARKED CLEAN *****
> >
> > ***** FILE SYSTEM WAS MODIFIED *****
> >
> > The usual stuff I would say.
>
> How is this usual?. It appears to me you did have some filesystem
> corruption.
>
What kind of filesystem corruption and how to solve that?
I see these messages frequently if a FreeBSD machine unexpectedly reboots. Not only on this
system but also on others. I never worried about it.
--
Met vriendelijke groeten,
With kind regards,
Mit freundlichen Gruessen,
De jrus wah,
Willy
*************************************
W.K. Offermans
Home: +31 45 544 49 44
Mobile: +31 653 27 16 23
e-mail: Willy@Offermans.Rompen.nl
Powered by ....
(__)
\\\'',)
\/ \ ^
.\._/_)
------------------------------
Message: 15
Date: Fri, 16 May 2008 17:42:06 +0200
From: Willy Offermans <Willy@Offermans.Rompen.nl>
Subject: Re: g_vfs_done error third part--PLEASE HELP!
To: Kris Kennaway <kris@FreeBSD.org>
Cc: freebsd-stable@FreeBSD.org
Message-ID: <20080516154206.GB9388@wiz.vpn.offrom.nl>
Content-Type: text/plain; charset=us-ascii
Hello Kris,
On Fri, May 16, 2008 at 02:43:24PM +0200, Kris Kennaway wrote:
> Willy Offermans wrote:
> >Hello Roland and FreeBSD friends,
> >
> >I'm sorry to be so quite for a while, but I went away for a vacation.
> >But now I'm back, I like to solve this issue.
> >
> >
> >On Mon, Apr 21, 2008 at 10:10:47PM +0200, Roland Smith wrote:
> >>On Mon, Apr 21, 2008 at 09:04:03PM +0200, Willy Offermans wrote:
> >>>Dear FreeBSD friends,
> >>>
> >>>It is already the third time that I report this error. Can someone help
> >>>me in solving this issue?
> >>Probably the reason that you hear so little is that you provide so
> >>little information. Most of us are not clairvoyant.
> >>
> >>>Over and over again and always after heavy disk I/O I see the following
> >>>errors in the log files. If I force ar0s1g to unmount the machine
> >>>spontaneously reboots. Nothing seriously seems to be damaged by this
> >>>act, but anyway I cannot afford something bad happening to this
> >>>production machine.
> >>Why would you force an unmount?
> >
> >Otherwise the device keeps on reporting to be unavailable and cannot be
> >unmounted:
> >
> >sun# umount /share/
> >umount: unmount of /share failed: Resource temporarily unavailable
> >
> >>>Apr 18 20:02:19 sun kernel:
> >>>g_vfs_done():ar0s1g[WRITE(offset=290725068800, length=4096)]error = 5
> >>>
> >>>I have no clue what the errors mean, since offsets of 290725068800,
> >>>290725072896, and 290725074944 seem to be ridiculous. Does anybody
> >>>have a clue what is going on?
> >>For starters, how big is ar0s1g? If the offset is in bytes, it is around
> >>270 GB, which is not that unusual in this day and age.
> >
> >I have to admit that I was a bit confused by an offset value of
> >290725068800. There is no indication of a unit, so I assumed that it
> >was sector but probably it is simply bytes and then indeed the number
> >does make sense.
> >>>I'm using FreeBSD 7.0, but found the error being reported before with
> >>>previous versions of FreeBSD. I can and will provide more details on
> >>>demand.
> >>What does 'df' say?
> >
> >Filesystem 1K-blocks Used Avail Capacity Mounted on
> >/dev/ar0s1a 20308398 230438 18453290 1% /
> >devfs 1 1 0 100% /dev
> >/dev/ar0s1d 21321454 3814482 15801256 19% /usr
> >/dev/ar0s1e 50777034 5331686 41383186 11% /var
> >/dev/ar0s1f 101554150 18813760 74616058 20% /home
> >/dev/ar0s1g 274977824 34564876 218414724 14% /share
> >
> >pretty normal I would say.
> >
> >>Did you notice any file corruption in the filesystem on ar0s1g?
> >
> >No the two disks are brand new and I did not encounter any noticeable
> >file corruption. However I assume that nowadays bad sectors on HD are
> >handled by the hardware and do not need any user interaction to correct
> >this. But maybe I'm totally wrong.
> >
> >>Unmount the filesystem and run fsck(8) on it. Does it report any errors?
> >
> >sun# fsck /dev/ar0s1g
> >** /dev/ar0s1g
> >** Last Mounted on /share
> >** Phase 1 - Check Blocks and Sizes
> >INCORRECT BLOCK COUNT I=34788357 (272 should be 264)
> >CORRECT? [yn] y
> >
> >INCORRECT BLOCK COUNT I=34789217 (296 should be 288)
> >CORRECT? [yn] y
> >
> >** Phase 2 - Check Pathnames
> >** Phase 3 - Check Connectivity
> >** Phase 4 - Check Reference Counts
> >** Phase 5 - Check Cyl groups
> >FREE BLK COUNT(S) WRONG IN SUPERBLK
> >SALVAGE? [yn] y
> >
> >SUMMARY INFORMATION BAD
> >SALVAGE? [yn] y
> >
> >BLK(S) MISSING IN BIT MAPS
> >SALVAGE? [yn] y
> >
> >182863 files, 17282440 used, 120206472 free (12448 frags, 15024253
> >blocks, 0.0% fragmentation)
> >
> >***** FILE SYSTEM MARKED CLEAN *****
> >
> >***** FILE SYSTEM WAS MODIFIED *****
> >
> >The usual stuff I would say.
>
> No, any form of filesystem corruption is not usual.
>
> >
> >>>Any hints are very much appreciated.
> >>Did you manage to create a partition larger than the disk is (using
> >>newfs's -s switch)? In that case it could be that you're trying to write
> >>past the end of the device.
> >
> >No, look to the following output:
> >
> >sun# bsdlabel -A /dev/ar0s1
> ># /dev/ar0s1:
> >type: unknown
> >disk: amnesiac
> >label:
> >flags:
> >bytes/sector: 512
> >sectors/track: 63
> >tracks/cylinder: 255
> >sectors/cylinder: 16065
> >cylinders: 60799
> >sectors/unit: 976751937
> >rpm: 3600
> >interleave: 1
> >trackskew: 0
> >cylinderskew: 0
> >headswitch: 0 # milliseconds
> >track-to-track seek: 0 # milliseconds
> >drivedata: 0
> >
> >8 partitions:
> ># size offset fstype [fsize bsize bps/cpg]
> > a: 41943040 0 4.2BSD 0 0 0
> > b: 8388608 41943040 swap
> > c: 976751937 0 unused 0 0 # "raw"
> >part, don't edit
> > d: 44040192 50331648 4.2BSD 2048 16384 28552
> > e: 104857600 94371840 4.2BSD 2048 16384 28552
> > f: 209715200 199229440 4.2BSD 2048 16384 28552
> > g: 567807297 408944640 4.2BSD 2048 16384 28552
> >
> >/dev/ar0s1g starts after 408944640*512/1024/1024=199680MB
> >
> >
> >So I have to conclude that the write error message does make sense and
> >that something seems to be wrong with the disks. The next question is
> >what can I do about it? Should I return the disks to the shop and ask
> >for new ones?
>
> #define EIO 5 /* Input/output error */
>
> At least one of your disks is toast.
>
> Kris
>
I doubt it, but you could be right. Do you have any suggestions to
investigate any further?
Since this is a production machine I have to operate extremely
carefully. I will transfer the data to other disks and will reboot
and run the system from the other disks. Then I will reformat the disks
again and restore the data. Lets see what happens.
--
Met vriendelijke groeten,
With kind regards,
Mit freundlichen Gruessen,
De jrus wah,
Willy
*************************************
W.K. Offermans
Home: +31 45 544 49 44
Mobile: +31 653 27 16 23
e-mail: Willy@Offermans.Rompen.nl
Powered by ....
(__)
\\\'',)
\/ \ ^
.\._/_)
------------------------------
Message: 16
Date: Fri, 16 May 2008 08:59:38 -0700
From: Jeremy Chadwick <koitsu@FreeBSD.org>
Subject: Re: g_vfs_done error third part--PLEASE HELP!
To: Willy Offermans <Willy@Offermans.Rompen.nl>
Cc: freebsd-stable@FreeBSD.org
Message-ID: <20080516155938.GA71548@eos.sc1.parodius.com>
Content-Type: text/plain; charset=us-ascii
On Fri, May 16, 2008 at 05:37:56PM +0200, Willy Offermans wrote:
> > > sun# fsck /dev/ar0s1g
> > > ** /dev/ar0s1g
> > > ** Last Mounted on /share
> > > ** Phase 1 - Check Blocks and Sizes
> > > INCORRECT BLOCK COUNT I=34788357 (272 should be 264)
> > > CORRECT? [yn] y
> > >
> > > INCORRECT BLOCK COUNT I=34789217 (296 should be 288)
> > > CORRECT? [yn] y
> > >
> > > ** Phase 2 - Check Pathnames
> > > ** Phase 3 - Check Connectivity
> > > ** Phase 4 - Check Reference Counts
> > > ** Phase 5 - Check Cyl groups
> > > FREE BLK COUNT(S) WRONG IN SUPERBLK
> > > SALVAGE? [yn] y
> > >
> > > SUMMARY INFORMATION BAD
> > > SALVAGE? [yn] y
> > >
> > > BLK(S) MISSING IN BIT MAPS
> > > SALVAGE? [yn] y
> > >
> > > 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253
> > > blocks, 0.0% fragmentation)
> > >
> > > ***** FILE SYSTEM MARKED CLEAN *****
> > >
> > > ***** FILE SYSTEM WAS MODIFIED *****
> > >
> > > The usual stuff I would say.
> >
> > How is this usual?. It appears to me you did have some filesystem
> > corruption.
>
> What kind of filesystem corruption and how to solve that?
That's difficult to answer, for a lot of reasons.
Your original post stated that you were seeing g_vfs_done errors on the
console, and you were worried about what they implied. Then someone
asked you "have you fsck'd the filesystem?", and you hadn't. Then you
did fsck it, and as can be seen above, the filesystem had errors.
When combined with your below comment, it's very difficult to figure out
what's going on with your system over there, or what information you're
not disclosing.
Additionally, kris@ has stated that it looks like you may have a hard
disk that's gone bad, and that's a strong possibility as well. SMART
statistics of the drives in your RAID array would be useful.
> I see these messages frequently if a FreeBSD machine unexpectedly reboots. Not only on this
> system but also on others. I never worried about it.
Are you saying the above errors experienced were caused by an unexpected
crash or reboot? If so, the filesystem should have been automatically
fsck'd shortly (60-120 seconds) after getting a "login:" prompt on the
console.
Is your filesystem UFS2 with softupdates enabled? If so, and the
automatic fsck didn't happen, then that's something separate to look
into -- it should happen automatically with softupdates enabled.
More importantly, though, would be the explanation for why your system
is crashing/rebooting/power-cycling. Data corruption can happen in
those situations, especially the latter, but any form of non-clean
shutdown should induce a fsck on UFS2+softupdate filesystems.
--
| Jeremy Chadwick jdc 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 |
------------------------------
Message: 17
Date: Fri, 16 May 2008 17:48:48 +0200
From: Zoran Kolic <zkolic@sbb.co.yu>
Subject: udf
To: freebsd-stable@freebsd.org
Message-ID: <20080516154848.GA1127@faust.net>
Content-Type: text/plain; charset=us-ascii
Howdy!
What is the experience regarding udf on cd/dvd on 7.0?
I saw netbsd mail few days ago having those steps:
newfs_udf and mount_udf.
Best regards
Zoran
------------------------------
Message: 18
Date: Fri, 16 May 2008 19:08:11 +0300
From: Stefan Lambrev <stefan.lambrev@moneybookers.com>
Subject: Re: udf
To: Zoran Kolic <zkolic@sbb.co.yu>
Cc: freebsd-stable@freebsd.org
Message-ID: <482DB16B.2070402@moneybookers.com>
Content-Type: text/plain; charset=windows-1251; format=flowed
Zoran Kolic wrote:
> Howdy!
> What is the experience regarding udf on cd/dvd on 7.0?
> I saw netbsd mail few days ago having those steps:
> newfs_udf and mount_udf.
> Best regards
>
From man mount_udf (FreeBSD7)
HISTORY
The mount_udf utility first appeared in FreeBSD 5.0.
FreeBSD 7.0 March 23, 2002
FreeBSD 7.0
I have no idea for newfs_udf , and what is supposed this to do :)
> Zoran
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
--
Best Wishes,
Stefan Lambrev
ICQ# 24134177
------------------------------
Message: 19
Date: Fri, 16 May 2008 09:10:17 -0700
From: Jeremy Chadwick <koitsu@FreeBSD.org>
Subject: Re: udf
To: Stefan Lambrev <stefan.lambrev@moneybookers.com>
Cc: freebsd-stable@freebsd.org, Zoran Kolic <zkolic@sbb.co.yu>
Message-ID: <20080516161017.GA72242@eos.sc1.parodius.com>
Content-Type: text/plain; charset=us-ascii
On Fri, May 16, 2008 at 07:08:11PM +0300, Stefan Lambrev wrote:
> From man mount_udf (FreeBSD7)
>
> HISTORY
> The mount_udf utility first appeared in FreeBSD 5.0.
>
> FreeBSD 7.0 March 23, 2002 FreeBSD
> 7.0
>
> I have no idea for newfs_udf , and what is supposed this to do :)
It creates a UDF (commonly DVD/DVD Audio) filesystem. NetBSD and
Solaris 10 both have this.
--
| Jeremy Chadwick jdc 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 |
------------------------------
Message: 20
Date: Fri, 16 May 2008 12:23:26 -0400
From: Sam Leffler <sam@freebsd.org>
Subject: Re: Hard(?) lock when reassociating ath with wpa_supplicant
on RELENG_7
To: "Alexandre \"Sunny\" Kovalenko" <alex.kovalenko@verizon.net>
Cc: stable@freebsd.org
Message-ID: <482DB4FE.3010300@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Alexandre "Sunny" Kovalenko wrote:
> On Mon, 2008-05-12 at 19:33 -0700, Sam Leffler wrote:
>> Alexandre "Sunny" Kovalenko wrote:
>>> I seem to be able to lock my machine by going into wpa_cli and asking it
>>> to 'reassoc'. The reason for question mark after "hard" is that debug
>>> information (caused by wlandebug and athdebug) is being printed on the
>>> console. The only way to get machine's attention is to hold power button
>>> for 8 seconds.
>> So this is just livelock due to console debug msgs.
> I am not sure, I have parsed this well enough, so I will try to clarify:
> machine becomes unresponsive *without* any debugging turned on, to an
> extent that pressing the power button twice *does not* generate ACPI
> console message (something to the tune of "going into S5 already --
> gimme a break"). If I turn ath debugging on, I do see those messages,
> and only them, scrolling on the console.
Guess I misunderstood you.
>>> Note: manual reassociation is just the handy way to reproduce the
>>> problem -- I have had machine locking up on me the whole day long
>>> completely on its own.
>>>
>>> Below are, what I think, relevant pieces of information. If anything is
>>> missing, please, chastise me appropriately and will do my best to
>>> provide. I have rigged firewire console, but am unable to break into the
>>> debugger locally or remotely.
>> I see no log msgs.
> I am sorry -- mailman must have eaten it up -- I have posted them here
> now:
>
> http://members.verizon.net/~akovalenko/Misc/reassoc.log.gz
All I see in the log is normal scanning.
>
>>> While I am on the subject, I would appreciate couple of the
>>> troubleshooting suggestions:
>>> * is there any way to get sysctl dev.ath.0.debug to appear, other then
>>> defining ATH_DEBUG in something like /usr/src/sys/dev/ath/ah_osdep.h?
>> options ATH_DEBUG
> That does not seem to work for if_ath built as the module, sorry for not
> being clear in that respect.
If you are build a module then you must edit the Makefile to add the
option. Feel free to provide a patch to improve this situation.
>
>>> * is there minimal, but still usable mask for athdebug and wlandebug? I
>>> have started with 0xFFFFFFFF and kept trimming likely high-volume
>>> settings until output slowed down to the reasonable pace.
>> Why do you want debug msgs from ath? The debug msgs from wlandebug
>> depend on what you're trying to debug.
> Because neither wpa_supplicant (quoted below), nor wlandebug (in the URL
> above) gave me the answer -- it looks like we are going into the scan
> with the specific SSID in mind and never come back, so I went for the
> next level. However, could you, please, clarify that I understood you
> correctly -- you *do not* want to see mix of wlandebug and athdebug
> messages in the report, and I should turn wlandebug off before turning
> athdebug on, right?
wlandebug msgs are typically low duty and can be left enabled when you
add driver-level debug msgs. But I can't see from the log you sent what
is going on. Try reducing the noise by eliminating all the ath debug
msgs; maybe provide one log w/ only wlan msgs and one w/ wlan+ath.
>
>> I suggest that when debugging you start from the highest layer and move
>> downward. If you can't find what you need in a wpa_supplicant log then
>> turn on msgs in net80211 with wlandebug. If that doesn't tell you what
>> you need then move to the driver. Blindly turning everything on can
>> easily livelock your system.
> That's what I did -- what I have posted is the end result of the walking
> down that chain, and I assumed, possibly incorrectly, that you would
> want result of all three to put things in context. I do apologize for
> the misunderstanding.
>
>> For high volume msgs I often do something
>> like:
>>
>> athdebug +intr; sleep 1; athdebug -intr
>>
>> or
>>
>> athdebug +intr; read x; athdebug -intr
>>
>> so a carriage return will disable msgs.
> Thank you for the suggestion.
>
>>
>>> * what facility does wpa_supplicant use, when forced to syslog by -s
>>> switch?
>> trouble% cd /data/freebsd/head/contrib/wpa_supplicant/
>> trouble% grep openlog *.c
>> common.c: openlog("wpa_supplicant", LOG_PID | LOG_NDELAY, LOG_DAEMON);
> Thank you, should have done this myself, sorry.
>
------------------------------
Message: 21
Date: Fri, 16 May 2008 10:48:04 -0600
From: Scott Long <scottl@samsco.org>
Subject: Re: udf
To: Jeremy Chadwick <koitsu@freebsd.org>
Cc: Zoran Kolic <zkolic@sbb.co.yu>, freebsd-stable@freebsd.org, Stefan
Lambrev <stefan.lambrev@moneybookers.com>
Message-ID: <482DBAC4.30101@samsco.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Jeremy Chadwick wrote:
> On Fri, May 16, 2008 at 07:08:11PM +0300, Stefan Lambrev wrote:
>> From man mount_udf (FreeBSD7)
>>
>> HISTORY
>> The mount_udf utility first appeared in FreeBSD 5.0.
>>
>> FreeBSD 7.0 March 23, 2002 FreeBSD
>> 7.0
>>
>> I have no idea for newfs_udf , and what is supposed this to do :)
>
> It creates a UDF (commonly DVD/DVD Audio) filesystem. NetBSD and
> Solaris 10 both have this.
>
There is no write support in UDF in FreeBSD. When I wrote the fs code,
packet writing was the only way to do discrete writes, and it's very
hard to make that work with a traditional VM system. Now with DVD+R,
it's probably worth someone's time to look at it (though the append-only
nature of +R means that there are still some nasty VM complications to
deal with). Until that happens, mkisofs can be used to create a static
UDF filesystem.
Scott
------------------------------
Message: 22
Date: Fri, 16 May 2008 19:20:44 +0100
From: Thomas Hurst <tom.hurst@clara.net>
Subject: Re: Approaching the limit on PV entries, consider increasing
either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.
To: Evren Yurtesen <yurtesen@ispro.net>
Cc: Jeremy Chadwick <koitsu@FreeBSD.org>, freebsd-stable@freebsd.org
Message-ID: <20080516182044.GA5921@voi.aagh.net>
Content-Type: text/plain; charset=us-ascii
* Evren Yurtesen (yurtesen@ispro.net) wrote:
> I guess one good question is, how can one see the number of PV entries
> used by a process? shouldnt these appear in the output of ipcs -a
> command?
No, PV entries are a VM thing, not limited to SysV IPC.
> Another good question is, in many places there is references to
> rebooting after putting a new vm.pmap.shpgperproc value to
> loader.conf. However I just changed this on a running system, has it
> really been changed or was I suppose to reboot?
Looking at the code it should be fine, the limit's just a couple of
integers.
> In either case, I already increased vm.pmap.shpgperproc to 2000 (from
> 200) and still the error occurs, there is not so much load on this
> box, maybe there is a leak somewhere?
What sort of load is there? Do you have a bunch of big processes
sharing significant chunks of memory in any way?
--
Thomas 'Freaky' Hurst
------------------------------
Message: 23
Date: Fri, 16 May 2008 21:36:00 +0300
From: Evren Yurtesen <yurtesen@ispro.net>
Subject: Re: Approaching the limit on PV entries, consider increasing
either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.
To: Evren Yurtesen <yurtesen@ispro.net>, Jeremy Chadwick
<koitsu@FreeBSD.org>, freebsd-stable@freebsd.org
Message-ID: <482DD410.6090102@ispro.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Thomas Hurst wrote:
>> In either case, I already increased vm.pmap.shpgperproc to 2000 (from
>> 200) and still the error occurs, there is not so much load on this
>> box, maybe there is a leak somewhere?
>
> What sort of load is there? Do you have a bunch of big processes
> sharing significant chunks of memory in any way?
>
How do I see what process is sharing memory and how much memory?
There are a bunch of apache 2.2 processes working normally about 20-30
processes. This box doesnt do much more than that...
I just checked the machine and here is what it looks like:
2:32PM up 18 days, 5:40, 3 users, load averages: 0.41, 0.36, 0.27
web:/root#ps ax |grep http
21429 ?? Ss 0:18.08 /usr/local/sbin/httpd
86473 ?? S 0:00.09 /usr/local/sbin/httpd
86659 ?? S 0:00.09 /usr/local/sbin/httpd
86851 ?? S 0:00.07 /usr/local/sbin/httpd
86857 ?? S 0:00.04 /usr/local/sbin/httpd
86912 ?? S 0:00.04 /usr/local/sbin/httpd
86918 ?? S 0:00.03 /usr/local/sbin/httpd
86919 ?? S 0:00.03 /usr/local/sbin/httpd
86996 ?? S 0:00.04 /usr/local/sbin/httpd
87023 ?? S 0:00.02 /usr/local/sbin/httpd
87028 ?? S 0:00.03 /usr/local/sbin/httpd
87059 ?? S 0:00.01 /usr/local/sbin/httpd
87060 ?? S 0:00.01 /usr/local/sbin/httpd
87062 ?? S 0:00.02 /usr/local/sbin/httpd
87065 ?? S 0:00.03 /usr/local/sbin/httpd
87074 ?? S 0:00.01 /usr/local/sbin/httpd
87076 ?? S 0:00.02 /usr/local/sbin/httpd
87077 ?? S 0:00.03 /usr/local/sbin/httpd
87079 ?? S 0:00.04 /usr/local/sbin/httpd
87081 ?? S 0:00.03 /usr/local/sbin/httpd
87083 ?? S 0:00.03 /usr/local/sbin/httpd
87085 ?? S 0:00.04 /usr/local/sbin/httpd
87090 ?? S 0:00.02 /usr/local/sbin/httpd
87190 p1 R+ 0:00.00 grep http
web:/root#
Although I see now that for 2 days the PV entries error did not appear. I wonder
if it is spooling up somehow...
There is a cron job restarting apache everyday at midnight so it cant be apache
leaking perhaps.
Thanks,
Evren
------------------------------
Message: 24
Date: Fri, 16 May 2008 21:07:18 +0200
From: Roland Smith <rsmith@xs4all.nl>
Subject: Re: g_vfs_done error third part--PLEASE HELP!
To: Willy Offermans <Willy@Offermans.Rompen.nl>
Cc: freebsd-stable@freebsd.org
Message-ID: <20080516190718.GA73178@slackbox.xs4all.nl>
Content-Type: text/plain; charset="us-ascii"
On Fri, May 16, 2008 at 02:14:14PM +0200, Willy Offermans wrote:
> Filesystem 1K-blocks Used Avail Capacity Mounted on
> /dev/ar0s1a 20308398 230438 18453290 1% /
> devfs 1 1 0 100% /dev
> /dev/ar0s1d 21321454 3814482 15801256 19% /usr
> /dev/ar0s1e 50777034 5331686 41383186 11% /var
> /dev/ar0s1f 101554150 18813760 74616058 20% /home
> /dev/ar0s1g 274977824 34564876 218414724 14% /share
>
> pretty normal I would say.
Yes.
> > Did you notice any file corruption in the filesystem on ar0s1g?
>
> No the two disks are brand new and I did not encounter any noticeable
> file corruption. However I assume that nowadays bad sectors on HD are
> handled by the hardware and do not need any user interaction to correct
> this. But maybe I'm totally wrong.
Every ATA disk has spare sectors, and they usually don't report bad
blocks untill the spares are exhausted. In which case it is prudent to
replace the disk.
> > Unmount the filesystem and run fsck(8) on it. Does it report any errors?
>
> sun# fsck /dev/ar0s1g
> ** /dev/ar0s1g
> ** Last Mounted on /share
> ** Phase 1 - Check Blocks and Sizes
> INCORRECT BLOCK COUNT I=34788357 (272 should be 264)
> CORRECT? [yn] y
>
> INCORRECT BLOCK COUNT I=34789217 (296 should be 288)
> CORRECT? [yn] y
>
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
> FREE BLK COUNT(S) WRONG IN SUPERBLK
> SALVAGE? [yn] y
>
> SUMMARY INFORMATION BAD
> SALVAGE? [yn] y
>
> BLK(S) MISSING IN BIT MAPS
> SALVAGE? [yn] y
>
> 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253
> blocks, 0.0% fragmentation)
>
> ***** FILE SYSTEM MARKED CLEAN *****
>
> ***** FILE SYSTEM WAS MODIFIED *****
>
> The usual stuff I would say.
Disk corruption is never normal. It can be explained by if the machine
crashed or was power-cycles before the disks were unmounted, but it can
also indicate hardware troubles.
> > > Any hints are very much appreciated.
> So I have to conclude that the write error message does make sense and
> that something seems to be wrong with the disks. The next question is
> what can I do about it? Should I return the disks to the shop and ask
> for new ones?
Install sysutils/smartmontools, and run 'smartctl -A /dev/adX|less', where X
are the numbers of the drives in the RAID array.
In the output, look at the values for Reallocated_Sector_Ct,
Current_Pending_Sector, Offline_Uncorrectable, which is the last number
that you see on each line.
A small number for Reallocated_Sector_Ct is allowable. But non-zero counts
for Current_Pending_Sector or Offline_Uncorrectable means it's time to
get a new disk.
> However other people that I have contacted and who had a similar
> problem before have solved it by using software raid setup instead of a
> hardware raid setup. This seems to indicate that there is some bug in
> the FreeBSD code.
The RAID support that you find on most desktop motherboards _is_
software RAID. See ataraid(4).
Roland
--
R.F.Smith
http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080516/e444d986/attachment-0001.pgp
------------------------------
Message: 25
Date: Fri, 16 May 2008 23:11:16 +0400
From: Lev Serebryakov <lev@FreeBSD.org>
Subject: Re: FreeBSD 7.0-STABLE: "mount_nfs" vs "mount -t nfs":
problems with second one, UDP timeouts and ICMP ports unreach?!
To: freebsd-stable@freebsd.org
Message-ID: <625532066.20080516231116@serebryakov.spb.ru>
Content-Type: text/plain; charset=koi8-r
Hello, freebsd-stable.
You wrote 16 ��� 2008 �., 14:40:18:
> There is NO any firewalls on B. And, I repeat, it WORKS when I call
> mount_nfs directly in a moment!
Adding `-o -c' to mount (to pass `-c' to mount_nfs) helps. But I'm
very curious WHY mount_nfs, called directly, work WITHOUT `-c'...
--
// Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>
------------------------------
Message: 26
Date: Sat, 17 May 2008 01:53:04 +0100
From: Thomas Hurst <tom.hurst@clara.net>
Subject: Re: Approaching the limit on PV entries, consider increasing
either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.
To: Evren Yurtesen <yurtesen@ispro.net>
Cc: Jeremy Chadwick <koitsu@FreeBSD.org>, freebsd-stable@freebsd.org
Message-ID: <20080517005304.GA63122@voi.aagh.net>
Content-Type: text/plain; charset=us-ascii
* Evren Yurtesen (yurtesen@ispro.net) wrote:
> How do I see what process is sharing memory and how much memory?
Guessing is normally sufficient; typically it's processes with the same
name and similar size/res. On 7-STABLE you can use procstat -v to look
at the VM mappings for a process, but typically that'll be overkill.
> There are a bunch of apache 2.2 processes working normally about 20-30
> processes. This box doesnt do much more than that...
>
> I just checked the machine and here is what it looks like:
> 2:32PM up 18 days, 5:40, 3 users, load averages: 0.41, 0.36, 0.27
>
> web:/root#ps ax |grep http
> 21429 ?? Ss 0:18.08 /usr/local/sbin/httpd
> 86473 ?? S 0:00.09 /usr/local/sbin/httpd
> 86659 ?? S 0:00.09 /usr/local/sbin/httpd
>
> Although I see now that for 2 days the PV entries error did not appear. I
> wonder if it is spooling up somehow...
They do look a bit small to be triggering it; assuming they're sharing
most of that, that's still only about 400k pv entries; 5MB or so (12
bytes per entry). The systems I've seen pv entries run out on run to a
couple of orders of magnitude more than that.
> There is a cron job restarting apache everyday at midnight so it cant
> be apache leaking perhaps.
Load spikes maybe? Child count running into the stratosphere? Big PHP
opcode cache?
--
Thomas 'Freaky' Hurst
------------------------------
Message: 27
Date: Sat, 17 May 2008 15:38:29 +1000
From: Emil Mikulic <emikulic@gmail.com>
Subject: Re: ciss(4) not coping with large arrays?
To: Paul Saab <ps@mu.org>
Cc: freebsd-stable@freebsd.org, Claus Guttesen <kometen@gmail.com>
Message-ID: <20080517053829.GA73251@dmr.ath.cx>
Content-Type: text/plain; charset=us-ascii
On Fri, May 16, 2008 at 01:19:33AM -0700, Paul Saab wrote:
> Emil:
> > Running today's RELENG_7 (although 7.0-RELEASE has the same problem),
> > GENERIC kernel on an amd64 and I can't seem to get a da(4) device for
> > any arrays bigger than 2TB.
>
> Please try the following patch:
>
> http://yogurt.org/FreeBSD/ciss_large.diff
This works a treat!
da4 at ciss0 bus 0 target 4 lun 0
da4: <COMPAQ RAID 0 VOLUME OK> Fixed Direct Access SCSI-5 device
da4: 135.168MB/s transfers
da4: 3815350MB (7813837232 512 byte sectors: 255H 32S/T 65535C)
Double thanks for committing it, and for merging to RELENG_7!
--Emil
------------------------------
Message: 28
Date: Sat, 17 May 2008 09:52:23 +0200
From: Willy Offermans <Willy@Offermans.Rompen.nl>
Subject: Re: g_vfs_done error third part--PLEASE HELP!
To: Roland Smith <rsmith@xs4all.nl>
Cc: freebsd-stable@FreeBSD.ORG
Message-ID: <20080517075222.GA4250@wiz.vpn.offrom.nl>
Content-Type: text/plain; charset=us-ascii
Hello Roland and FreeBSD friends,
On Fri, May 16, 2008 at 09:07:18PM +0200, Roland Smith wrote:
> On Fri, May 16, 2008 at 02:14:14PM +0200, Willy Offermans wrote:
>
> > Filesystem 1K-blocks Used Avail Capacity Mounted on
> > /dev/ar0s1a 20308398 230438 18453290 1% /
> > devfs 1 1 0 100% /dev
> > /dev/ar0s1d 21321454 3814482 15801256 19% /usr
> > /dev/ar0s1e 50777034 5331686 41383186 11% /var
> > /dev/ar0s1f 101554150 18813760 74616058 20% /home
> > /dev/ar0s1g 274977824 34564876 218414724 14% /share
> >
> > pretty normal I would say.
>
> Yes.
>
> > > Did you notice any file corruption in the filesystem on ar0s1g?
> >
> > No the two disks are brand new and I did not encounter any noticeable
> > file corruption. However I assume that nowadays bad sectors on HD are
> > handled by the hardware and do not need any user interaction to correct
> > this. But maybe I'm totally wrong.
>
> Every ATA disk has spare sectors, and they usually don't report bad
> blocks untill the spares are exhausted. In which case it is prudent to
> replace the disk.
>
> > > Unmount the filesystem and run fsck(8) on it. Does it report any errors?
> >
> > sun# fsck /dev/ar0s1g
> > ** /dev/ar0s1g
> > ** Last Mounted on /share
> > ** Phase 1 - Check Blocks and Sizes
> > INCORRECT BLOCK COUNT I=34788357 (272 should be 264)
> > CORRECT? [yn] y
> >
> > INCORRECT BLOCK COUNT I=34789217 (296 should be 288)
> > CORRECT? [yn] y
> >
> > ** Phase 2 - Check Pathnames
> > ** Phase 3 - Check Connectivity
> > ** Phase 4 - Check Reference Counts
> > ** Phase 5 - Check Cyl groups
> > FREE BLK COUNT(S) WRONG IN SUPERBLK
> > SALVAGE? [yn] y
> >
> > SUMMARY INFORMATION BAD
> > SALVAGE? [yn] y
> >
> > BLK(S) MISSING IN BIT MAPS
> > SALVAGE? [yn] y
> >
> > 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253
> > blocks, 0.0% fragmentation)
> >
> > ***** FILE SYSTEM MARKED CLEAN *****
> >
> > ***** FILE SYSTEM WAS MODIFIED *****
> >
> > The usual stuff I would say.
>
> Disk corruption is never normal. It can be explained by if the machine
> crashed or was power-cycles before the disks were unmounted, but it can
> also indicate hardware troubles.
>
> > > > Any hints are very much appreciated.
>
> > So I have to conclude that the write error message does make sense and
> > that something seems to be wrong with the disks. The next question is
> > what can I do about it? Should I return the disks to the shop and ask
> > for new ones?
>
> Install sysutils/smartmontools, and run 'smartctl -A /dev/adX|less', where X
> are the numbers of the drives in the RAID array.
>
> In the output, look at the values for Reallocated_Sector_Ct,
> Current_Pending_Sector, Offline_Uncorrectable, which is the last number
> that you see on each line.
>
> A small number for Reallocated_Sector_Ct is allowable. But non-zero counts
> for Current_Pending_Sector or Offline_Uncorrectable means it's time to
> get a new disk.
sun# atacontrol status ar0
ar0: ATA RAID1 status: READY
subdisks:
0 ad4 ONLINE
1 ad6 ONLINE
So ad4 and ad6 are the HDs of the array.
sun# smartctl -A /dev/ad6
smartctl version 5.38 [i386-portbld-freebsd7.0] Copyright (C) 2002-8
Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 3
3 Spin_Up_Time 0x0007 100 100 015 Pre-fail Always - 7232
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 31
5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0
8 Seek_Time_Performance 0x0025 253 253 015 Pre-fail Offline - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 1478
10 Spin_Retry_Count 0x0033 253 253 051 Pre-fail Always - 0
11 Calibration_Retry_Count 0x0012 253 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 31
13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 439070649
187 Reported_Uncorrect 0x0032 253 253 000 Old_age Always - 0
188 Unknown_Attribute 0x0032 253 253 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 062 060 000 Old_age Always - 38
194 Temperature_Celsius 0x0022 124 115 000 Old_age Always - 38
195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 439070649
196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0
197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0
201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0
202 TA_Increase_Count 0x0032 253 253 000 Old_age Always - 0
un# smartctl -A /dev/ad4
smartctl version 5.38 [i386-portbld-freebsd7.0] Copyright (C) 2002-8
Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 109
3 Spin_Up_Time 0x0007 100 100 015 Pre-fail Always - 7360
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 32
5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0
8 Seek_Time_Performance 0x0025 253 253 015 Pre-fail Offline - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 1478
10 Spin_Retry_Count 0x0033 253 253 051 Pre-fail Always - 0
11 Calibration_Retry_Count 0x0012 253 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 31
13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 835531250
187 Reported_Uncorrect 0x0032 253 253 000 Old_age Always - 0
188 Unknown_Attribute 0x0032 253 253 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 062 060 000 Old_age Always - 38
194 Temperature_Celsius 0x0022 124 118 000 Old_age Always - 38
195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 835531250
196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0
197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0
201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0
202 TA_Increase_Count 0x0032 253 253 000 Old_age Always - 0
The critical values you have mentioned are all zero, but maybe you
notice some other oddities.
>
> > However other people that I have contacted and who had a similar
> > problem before have solved it by using software raid setup instead of a
> > hardware raid setup. This seems to indicate that there is some bug in
> > the FreeBSD code.
>
> The RAID support that you find on most desktop motherboards _is_
> software RAID. See ataraid(4).
Well then read motherboard supported raid instead of hardware raid!
What I meant was that Toomas noticed a similar problem and turned to
gmirror to ``solve'' the issue. But somewhere is something weird going on. I'm not the first
one to discover this and would be nice to nail it down, so that in the
future no one has to suffer anymore from this.
>
> Roland
> --
> R.F.Smith
http://www.xs4all.nl/~rsmith/
> [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
> pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
--
Met vriendelijke groeten,
With kind regards,
Mit freundlichen Gruessen,
De jrus wah,
Willy
*************************************
W.K. Offermans
Home: +31 45 544 49 44
Mobile: +31 653 27 16 23
e-mail: Willy@Offermans.Rompen.nl
Powered by ....
(__)
\\\'',)
\/ \ ^
.\._/_)
------------------------------
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
End of freebsd-stable Digest, Vol 252, Issue 10
***********************************************
发表者iFamp | 15:50:00
0 条评论:
发表评论
<< 主页