Re: gvinum / FreeBSD 6.1 / stale subdisks
Hello! On Thu, 17 Aug 2006, Steve Peterson wrote: I'm running FreeBSD 6.1-RELEASE on i386 with a stock kernel, and am trying to build a 4 disk RAID5 array using vinum. The issue is that, once the system is rebooted after initially creating the array, the subdisks come up as stale. 1 volume: V vol1 State: down Plexes: 1 Size:585 GB 1 plex: P vol1.p0R5 State: down Subdisks: 4 Size:585 GB 4 subdisks: S vol1.p0.s0State: staleD: drive01 Size:195 GB S vol1.p0.s1State: staleD: drive02 Size:195 GB S vol1.p0.s2State: staleD: drive03 Size:195 GB S vol1.p0.s3State: staleD: drive04 Size:195 GB gvinum - quit Try to issue 'start' command against your volume: gvinum start vol1 It seems that gvinum requires this action for newly-created volumes (luckily only once). If so, this fact should be stressed in both gvinum(8) and the Handbook. Also, the Handbook says that it covers the knowlege about 5.5 and 6.1 versions, so remnants of non-GEOM vinum(4) (which is defunct and unavailable at least in 6.x) should be removed for the sake of clarity. I'm not sure whether BUGS section in gvinum(8) should refer to the missing functionality of defunct vinum(4). Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: [EMAIL PROTECTED] nic-hdl: LYNX-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Q about gmirror's metadata sector
Hi If i've understood correctly gmirror uses the last sector on the provider for a metadata. If one uses http://www.onlamp.com/pub/a/bsd/2005/11/10/ FreeBSD_Basics.html to setup a gmirror'ed system, that is haveing a fully used disk where the last sector is used (right?) and converting it to a gmirror, this will overwrite whatever is on the last sector, right? This will probably not be overwritten on a non-full fs, but if the fs gets full later, is there any risk that this sector get's overwritten? Does one have to shrink the fs/slice manually or something to make sure this does not happend? I haven't seen anyone mention this anywhere so im just curious to how it works Thanks Johan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TOP shows above 100% WCPU usage
On Thu, 2006-Aug-17 10:57:04 -0400, Bill LeFebvre wrote:
Dan Nelson wrote:
I just built top-3.6 on such a system, though, and it does report a
simple main(){for(;;);} process as consuming 100 %CPU. Maybe you're
thinking of Solaris's own prstat command?
Heh. I released 3.6 with new SunOS code that didn't adjust for number of
cpus, and someone flagged the behavior as a bug. So you're right: 3.6
doesn't do it this way. But 3.5 did, and it seems at least some people
prefer it that way.
I actually prefer this new behaviour. One of my major uses of top is
identifying processes that are spinning for one reason or another.
Having a process show up as 99-100% is quite obvious and I can then
look closer to see if that process is validly using 100% CPU or not.
Having a process using 3.1% CPU (on a 32-CPU system) would be far less
obvious. (In my case, I'm scanning instaneous top outputs from ~60
hosts so I don't want to have to study each output too closely).
To my way of thinking, %CPU is a percentage of a single CPU. If a
box has 32 CPUs, then maximum load is 3200% of a single CPU.
I think there are probably equally good rationales for each approach.
Probably the best situation is a flag to toggle between the two
approaches, together with two different titles to make it clear which
is being used.
--
Peter Jeremy
pgpi7kgmNNaFt.pgp
Description: PGP signature
Re: Unexplained kernel panic on 5-STABLE (now in 6-STABLE)
On Thu, 2006-Aug-17 15:18:21 -0400, Kris Kennaway wrote: On Thu, Aug 17, 2006 at 01:24:48PM -0400, John Baldwin wrote: On Thursday 17 August 2006 04:20, Peter van Heusden wrote: kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 151698, size: 28672 This can indicate that your swap disk is failing (or you are using a nonstandard swap setup like swapping to a file); it means that the kernel timed out trying to read/write from swap. I think this can also mean that another device on that channel/bus is failing and tying up the bus for an extended period. I think I've seen this error from an IDE disk when the CD-ROM slave on the same bus was flaky. -- Peter Jeremy pgph8WO3y2Wlu.pgp Description: PGP signature
Re: FreeBSD boots too fast on Dell PE850
2006/8/18, Dan Nelson [EMAIL PROTECTED]:
In the last episode (Aug 17), Alan Amesbury said:
OK, booting *too* quickly is a somewhat unusual problem. I have
FreeBSD 6.1-RELEASE-p3 running on a Dell PowerEdge 850. For some
reason, in the PowerEdge 850 Dell chose to replace the perfectly
adequate em(4) adapters found on the PE750 with bge(4) hardware.
FreeBSD identifies these adapters as BCM5750A1, but Dell says they're
actually Broadcom 5721J adapters instead. See
http://www.dell.com/downloads/global/products/pedge/en/850_specs.pdf
for details. The switch to which the host is connected is a Cisco
Catalyst 3750. How this relates to FreeBSD, however.
Have you enabled portfast on the Cisco?
http://www.cisco.com/warp/public/473/12.html#c2k
We have similar problems on various hardware and we also believe it's
caused by the Spanning Tree Protocol procedure done during the switch
port initialization. I don't like the idea of using portfast as it
makes the switch less robust so I tried to delay the boot using an rc
script as well:
/etc/rc.d/slow_interface_startup:
---
#!/bin/sh
# PROVIDE: slow_interface_startup
# REQUIRE: netif
# BEFORE: NETWORKING
slow_interface_startup_enable=${slow_interface_startup_enable:-NO}
slow_interface_startup_duration=${slow_interface_startup_duration:-50}
. /etc/rc.subr
name=slow_interface_startup
rcvar=`set_rcvar`
start_cmd=slow_interface_startup_start
stop_cmd=:
slow_interface_startup_start() {
echo -n Waiting for interfaces to get ready \
($slow_interface_startup_duration seconds)
sleep $slow_interface_startup_duration
echo
}
load_rc_config $name
run_rc_command $1
---
Then you can add to rc.conf:
slow_interface_startup_enable=YES
And optionally also (in seconds):
slow_interface_startup_duration=123
It's a little hack but it works as expected. Anyway, in some cases it
does not help. The NIC is probably reset at some later point. I have
not investigated it further yet.
Another thing to check is whether you have alias IPs. I believe the
bge driver has to reset the card every time you add or remove an IP.
I know the ti driver (whose chipset the broadcom chips are based on)
had that problem.
Yes, but I believe that all such operations are done by the netif script.
Martin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
On Thu, Aug 17, 2006 at 09:16:43PM -0500, Dan Nelson wrote: In the last episode (Aug 17), Alan Amesbury said: OK, booting *too* quickly is a somewhat unusual problem. I have FreeBSD 6.1-RELEASE-p3 running on a Dell PowerEdge 850. For some reason, in the PowerEdge 850 Dell chose to replace the perfectly adequate em(4) adapters found on the PE750 with bge(4) hardware. FreeBSD identifies these adapters as BCM5750A1, but Dell says they're actually Broadcom 5721J adapters instead. See http://www.dell.com/downloads/global/products/pedge/en/850_specs.pdf for details. The switch to which the host is connected is a Cisco Catalyst 3750. How this relates to FreeBSD, however. Have you enabled portfast on the Cisco? http://www.cisco.com/warp/public/473/12.html#c2k Another thing to check is whether you have alias IPs. I believe the bge driver has to reset the card every time you add or remove an IP. I know the ti driver (whose chipset the broadcom chips are based on) had that problem. If there is a way to program multicasting filters correctly without resettting the hardware there is no need to reset hardware and it could be easily implemented in ether_ioctl(). -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
On Fri, Aug 18, 2006 at 10:51:07AM +0200, Martin Horcicka wrote:
2006/8/18, Dan Nelson [EMAIL PROTECTED]:
In the last episode (Aug 17), Alan Amesbury said:
OK, booting *too* quickly is a somewhat unusual problem. I have
FreeBSD 6.1-RELEASE-p3 running on a Dell PowerEdge 850. For some
reason, in the PowerEdge 850 Dell chose to replace the perfectly
adequate em(4) adapters found on the PE750 with bge(4) hardware.
FreeBSD identifies these adapters as BCM5750A1, but Dell says they're
actually Broadcom 5721J adapters instead. See
http://www.dell.com/downloads/global/products/pedge/en/850_specs.pdf
for details. The switch to which the host is connected is a Cisco
Catalyst 3750. How this relates to FreeBSD, however.
Have you enabled portfast on the Cisco?
http://www.cisco.com/warp/public/473/12.html#c2k
We have similar problems on various hardware and we also believe it's
caused by the Spanning Tree Protocol procedure done during the switch
port initialization. I don't like the idea of using portfast as it
makes the switch less robust so I tried to delay the boot using an rc
script as well:
/etc/rc.d/slow_interface_startup:
---
#!/bin/sh
# PROVIDE: slow_interface_startup
# REQUIRE: netif
# BEFORE: NETWORKING
slow_interface_startup_enable=${slow_interface_startup_enable:-NO}
slow_interface_startup_duration=${slow_interface_startup_duration:-50}
. /etc/rc.subr
name=slow_interface_startup
rcvar=`set_rcvar`
start_cmd=slow_interface_startup_start
stop_cmd=:
slow_interface_startup_start() {
echo -n Waiting for interfaces to get ready \
($slow_interface_startup_duration seconds)
sleep $slow_interface_startup_duration
echo
}
load_rc_config $name
run_rc_command $1
---
Then you can add to rc.conf:
slow_interface_startup_enable=YES
And optionally also (in seconds):
slow_interface_startup_duration=123
It's a little hack but it works as expected. Anyway, in some cases it
does not help. The NIC is probably reset at some later point. I have
not investigated it further yet.
Another thing to check is whether you have alias IPs. I believe the
bge driver has to reset the card every time you add or remove an IP.
I know the ti driver (whose chipset the broadcom chips are based on)
had that problem.
Yes, but I believe that all such operations are done by the netif script.
I think it's job of device driver. If the driver find its link
negotiation is in progress it should not send frames.
Unfortunately not all drivers handle this correctly.
--
Regards,
Pyun YongHyeon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
On Fri, Aug 18, 2006 at 06:22:56PM +0900, Pyun YongHyeon wrote: On Fri, Aug 18, 2006 at 10:51:07AM +0200, Martin Horcicka wrote: 2006/8/18, Dan Nelson [EMAIL PROTECTED]: In the last episode (Aug 17), Alan Amesbury said: OK, booting *too* quickly is a somewhat unusual problem. I have FreeBSD 6.1-RELEASE-p3 running on a Dell PowerEdge 850. For some reason, in the PowerEdge 850 Dell chose to replace the perfectly adequate em(4) adapters found on the PE750 with bge(4) hardware. [...] It's a little hack but it works as expected. Anyway, in some cases it does not help. The NIC is probably reset at some later point. I have not investigated it further yet. Another thing to check is whether you have alias IPs. I believe the bge driver has to reset the card every time you add or remove an IP. I know the ti driver (whose chipset the broadcom chips are based on) had that problem. Yes, but I believe that all such operations are done by the netif script. I think it's job of device driver. If the driver find its link negotiation is in progress it should not send frames. Unfortunately not all drivers handle this correctly. But the bge's start() routine does this, and did it in 6.1-RELEASE, so it doesn't look like a problem in this particular case. : if (!sc-bge_link || IFQ_DRV_IS_EMPTY(ifp-if_snd)) : return; Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpxP9mBvWi35.pgp Description: PGP signature
Re: FreeBSD boots too fast on Dell PE850
2006/8/18, Pyun YongHyeon [EMAIL PROTECTED]: On Fri, Aug 18, 2006 at 10:51:07AM +0200, Martin Horcicka wrote: 2006/8/18, Dan Nelson [EMAIL PROTECTED]: In the last episode (Aug 17), Alan Amesbury said: OK, booting *too* quickly is a somewhat unusual problem. I have FreeBSD 6.1-RELEASE-p3 running on a Dell PowerEdge 850. For some reason, in the PowerEdge 850 Dell chose to replace the perfectly adequate em(4) adapters found on the PE750 with bge(4) hardware. FreeBSD identifies these adapters as BCM5750A1, but Dell says they're actually Broadcom 5721J adapters instead. See http://www.dell.com/downloads/global/products/pedge/en/850_specs.pdf for details. The switch to which the host is connected is a Cisco Catalyst 3750. How this relates to FreeBSD, however. Have you enabled portfast on the Cisco? http://www.cisco.com/warp/public/473/12.html#c2k We have similar problems on various hardware and we also believe it's caused by the Spanning Tree Protocol procedure done during the switch port initialization. I don't like the idea of using portfast as it makes the switch less robust so I tried to delay the boot using an rc script as well: ... I think it's job of device driver. If the driver find its link negotiation is in progress it should not send frames. Unfortunately not all drivers handle this correctly. Unfortunately, I don't know how it works exactly. In our case when the autodetection is disabled and there is e.g. 100/full configured manually on both, switch and the FreeBSD box, ifconfig shows the interface status wery early as active. I suspect the switch (Cisco) to activate the port (from the point of view of the FreeBSD box) but not to forward any normal frames until the Spanning Tree Protocol procedure is finished for that port. But it's just a guess. I don't know the negotiation protocol in Ethernet at all and I would really welcome a commentary from someone who does. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
Hi, all! On Fri, Aug 18, 2006 at 01:23:15PM +0200, Martin Horcicka wrote: Unfortunately, I don't know how it works exactly. In our case when the autodetection is disabled and there is e.g. 100/full configured manually on both, switch and the FreeBSD box, ifconfig shows the interface status wery early as active. I suspect the switch (Cisco) to activate the port (from the point of view of the FreeBSD box) but not to forward any normal frames until the Spanning Tree Protocol procedure is finished for that port. But it's just a guess. I don't know the negotiation protocol in Ethernet at all and I would really welcome a commentary from someone who does. This is indeed the case. The switch port goes up. Then the port goes into either the forwarding or the blocking state. The transition period usually takes between 30 and 50 seconds, which may be to long for some devices. spanning-tree portfast puts the port into the forwarding state immediately but still participates in STP, so eventually a loop will be detected and the port put back into blocking state again. The layer 2 interface is, of course, up during all this mumble - otherwise the switch could not send receive STP frames. This is what confuses hosts waiting for DHCP or similar. HTH, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
2006/8/18, Patrick M. Hausen [EMAIL PROTECTED]: On Fri, Aug 18, 2006 at 01:23:15PM +0200, Martin Horcicka wrote: Unfortunately, I don't know how it works exactly. In our case when the autodetection is disabled and there is e.g. 100/full configured manually on both, switch and the FreeBSD box, ifconfig shows the interface status wery early as active. I suspect the switch (Cisco) to activate the port (from the point of view of the FreeBSD box) but not to forward any normal frames until the Spanning Tree Protocol procedure is finished for that port. But it's just a guess. I don't know the negotiation protocol in Ethernet at all and I would really welcome a commentary from someone who does. This is indeed the case. The switch port goes up. Then the port goes into either the forwarding or the blocking state. The transition period usually takes between 30 and 50 seconds, which may be to long for some devices. spanning-tree portfast puts the port into the forwarding state immediately but still participates in STP, so eventually a loop will be detected and the port put back into blocking state again. This is a little off-topic (and I'm no Cisco specialist) but I'm afraid that the loop detection won't happen with portfast. Cisco.com says (the first page that Google gave me): --- Understanding How PortFast Works Spanning-tree PortFast causes a port to enter the spanning-tree forwarding state immediately, bypassing the listening and learning states. You can use PortFast on switch ports connected to a single workstation or server to allow those devices to connect to the network immediately, rather than waiting for the port to transition from the listening and learning states to the forwarding state. Caution: PortFast should be used only when connecting a single end station to a switch port. If you enable PortFast on a port connected to another networking device, such as a switch, you can create network loops. When the switch powers up, or when a device is connected to a port, the port normally enters the spanning-tree listening state. When the forward delay timer expires, the port enters the learning state. When the forward delay timer expires a second time, the port is transitioned to the forwarding or blocking state. When you enable PortFast on a port, the port is immediately and permanently transitioned to the spanning-tree forwarding state. --- But then I don't see any difference between using portfast and disabling Spanning Tree Protocol frames for that port at all. :-/ Martin The layer 2 interface is, of course, up during all this mumble - otherwise the switch could not send receive STP frames. This is what confuses hosts waiting for DHCP or similar. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld does nothing
I don't know if fixing your broken shell is within its list of powers :-) Kris alright, it was bash :( stupid shell. I'll just keep csh for root's shell - it's a bit annoying sometimes, but still good enough to do the little what needs to be done sometimes :D thanks a bunch tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld does nothing
On Fri, Aug 18, 2006 at 02:02:19PM +0200, Tom Hummel wrote: I don't know if fixing your broken shell is within its list of powers :-) Kris alright, it was bash :( stupid shell. I'll just keep csh for root's shell - it's a bit annoying sometimes, but still good enough to do the little what needs to be done sometimes :D FYI, standard practice is to use the toor account for super-user-with-nonstandard-shell. Also as someone else said the bash port is probably fixed already if you update it. Kris pgpzd0NMDhZ6S.pgp Description: PGP signature
Re: make buildworld does nothing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Hummel wrote: | alright, it was bash :( stupid shell. | I'll just keep csh for root's shell - it's a bit annoying sometimes, but | still good enough to do the little what needs to be done sometimes :D FWIW I use /bin/tcsh as the root shell since it includes command-line editing and my fingers are often dyslexic before a sufficient caffeine intake ;-) 'buildworld' works with it, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE5a4nQv9rrgRC1JIRArOlAJ9l712od+QvqFI/Ew53SZB7kWsobACgpAPn yB2qGkvYch1fT+phBe8EsdA= =MzQK -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld does nothing
FWIW I use /bin/tcsh as the root shell since it includes command-line editing and my fingers are often dyslexic before a sufficient caffeine intake ;-) 'buildworld' works with it, I dont want to use anything not in base for root's login shell tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
2006/8/18, Patrick M. Hausen [EMAIL PROTECTED]: On Fri, Aug 18, 2006 at 01:23:15PM +0200, Martin Horcicka wrote: Unfortunately, I don't know how it works exactly. In our case when the autodetection is disabled and there is e.g. 100/full configured manually on both, switch and the FreeBSD box, ifconfig shows the interface status wery early as active. I suspect the switch (Cisco) to activate the port (from the point of view of the FreeBSD box) but not to forward any normal frames until the Spanning Tree Protocol procedure is finished for that port. But it's just a guess. I don't know the negotiation protocol in Ethernet at all and I would really welcome a commentary from someone who does. This is indeed the case. The switch port goes up. Then the port goes into either the forwarding or the blocking state. The transition period usually takes between 30 and 50 seconds, which may be to long for some devices. spanning-tree portfast puts the port into the forwarding state immediately but still participates in STP, so eventually a loop will be detected and the port put back into blocking state again. This is a little off-topic (and I'm no Cisco specialist) but I'm afraid that the loop detection won't happen with portfast. Cisco.com says (the first page that Google gave me): --- Understanding How PortFast Works Spanning-tree PortFast causes a port to enter the spanning-tree forwarding state immediately, bypassing the listening and learning states. You can use PortFast on switch ports connected to a single workstation or server to allow those devices to connect to the network immediately, rather than waiting for the port to transition from the listening and learning states to the forwarding state. Caution: PortFast should be used only when connecting a single end station to a switch port. If you enable PortFast on a port connected to another networking device, such as a switch, you can create network loops. When the switch powers up, or when a device is connected to a port, the port normally enters the spanning-tree listening state. When the forward delay timer expires, the port enters the learning state. When the forward delay timer expires a second time, the port is transitioned to the forwarding or blocking state. When you enable PortFast on a port, the port is immediately and permanently transitioned to the spanning-tree forwarding state. --- But then I don't see any difference between using portfast and disabling Spanning Tree Protocol frames for that port at all. :-/ because there isn't? if you are connecting a host to a switch, you can safely drop Spanning tree. from experience, even with SP enabled, the loop is detected, but not always the correct port is disabled :-(. danny Martin The layer 2 interface is, of course, up during all this mumble - otherwise the switch could not send receive STP frames. This is what confuses hosts waiting for DHCP or similar. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
Hi! This is a little off-topic (and I'm no Cisco specialist) but I'm afraid that the loop detection won't happen with portfast. Cisco.com says (the first page that Google gave me): [ Cisco documentation ] As always: it depends. In this case, what you imply by loop detection. If the loop is built using more Cisco equipment participating in STP, then the loop will be detected and eventually broken by putting one of the links in blocked state. IOS or CatOS bugs notwithstanding. Regards, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Data send to printer via /dev/lpt0 in 6.1-STABLE hangs
A bitmapfile for a printer send to /dev/lpt0 doesn't do anything, it just hangs: # cat bitmapfile /dev/lpt0 No error reports anywhere. Cannot be interrupted with ^C or ^Z Any other mode with lptcontrol does not have any effect. Same configuration in 6.1-Release works o.k. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The need for initialising disks before use?
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. -- Kirk Strauser The Day Companies ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The need for initialising disks before use?
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. -- Brooks [0] The error occured in one of the worst possible locations and fsck could not complete until I zeroed those locations. That really sucked. pgp9MRru4oamG.pgp Description: PGP signature
Re: Q about gmirror's metadata sector
On Aug 18, 2006, at 3:29 AM, Johan Ström wrote: If i've understood correctly gmirror uses the last sector on the provider for a metadata. If one uses http://www.onlamp.com/pub/a/bsd/2005/11/10/ FreeBSD_Basics.html to setup a gmirror'ed system, that is haveing a fully used disk where the last sector is used (right?) and converting it to a gmirror, this will overwrite whatever is on the last sector, right? This will probably not be overwritten on a non-full fs, but if the fs gets full later, is there any risk that this sector get's overwritten? Does one have to shrink the fs/slice manually or something to make sure this does not happend? take a look at your fdisk output and see if the last few hundred sectors of your disk are used at all by any file system. I doubt they are.
Re: FreeBSD boots too fast on Dell PE850
On Aug 17, 2006, at 9:49 PM, Alan Amesbury wrote: adequate em(4) adapters found on the PE750 with bge(4) hardware. FreeBSD identifies these adapters as BCM5750A1, but Dell says they're actually Broadcom 5721J adapters instead. See http://www.dell.com/downloads/global/products/pedge/en/850_specs.pdf I'm not sure how much to believe the dell docs... on a PE800, they claim the system has a BCM5721 chip, which is how it was coded into the bge driver when I first got this machine and helped get patches built for it. However, the pciconf database claims it is a BCM5750A1. Which one is correct? I suspect the latter. I have PR's open on resolving this inconsistency, but they are obviously low priority. I have no problems with the delay in the 'active' status, but I hard- code IP configuration since it is a server.
Re: make buildworld does nothing
Date: Fri, 18 Aug 2006 14:24:05 +0200 From: Tom Hummel [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] FWIW I use /bin/tcsh as the root shell since it includes command-line editing and my fingers are often dyslexic before a sufficient caffeine intake ;-) 'buildworld' works with it, I dont want to use anything not in base for root's login shell /bin/tcsh IS in base, but /bin/csh IS /bin/tcsh (Hard linked). FreeBSD dropped its old csh for tcsh about seven years ago. V4.3, I think. % ls -l /bin/*csh -r-xr-xr-x 2 root wheel 293060 May 23 20:43 /bin/csh -r-xr-xr-x 2 root wheel 293060 May 23 20:43 /bin/tcsh So /bin/csh (or /bin/tcsh) gives you full command editing and completion capability and all the other interactive tcsh goodies. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Support for Adaptec 2005S ZCR RAID ?
As I seem to recallt sme discussion of Adaptec RAID in the not so disatnt past, could anyone let me know if these cards work well under FreeBSD 6 or not ? I've just inherited a server which needs RAIDing and it has a slot for one of these on the board. I only have expereience of Compaq SMART RAID myself, so have no idea if this is any good or not. Any advice is welcomed. thanks, -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Data send to printer via /dev/lpt0 in 6.1-STABLE hangs
On Friday 18 August 2006 14:50, Kees Plonsz wrote: A bitmapfile for a printer send to /dev/lpt0 doesn't do anything, it just hangs: # cat bitmapfile /dev/lpt0 No error reports anywhere. Cannot be interrupted with ^C or ^Z Any other mode with lptcontrol does not have any effect. Same configuration in 6.1-Release works o.k. Found it. plip0 interface was default up. Should be default down My Canon printer was seen as a point to point interface. Nice joke :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
Thanks for the feedback and discussion! Alas, in terms of network configuration, I'm just a tenant; I have no direct control over the networking gear, nor direct visibility into how the switch is configured. A couple people wrote to me directly and suggested I 'send-pr' this, so I'll do so (hopefully later today). Thanks again! -- Alan Amesbury University of Minnesota ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RocketRAID 2224
I am attemping to use a RocketRAID 2224 8 channel card to set up a storage server. The server board is an Intel SE7230NH1-E with a P4-D 2.8GHz, 2GB RAM. FreeBSD doesn't see it at all. I've noticed that the kernel config has options built in for the RocketRAID 182x. Are there options I can add for the newer card? If so, will they work with FreeBSD 6.1 so that I can reconfigure for it rather than 6.0 that's running now? Basically we're trying to set up backups to disk with a RAID of about 4.5TB. Thanks for any help. -- Dave *** There are 10 types of people. Those who understand binrary ... ...and those who don't ### David Kingsley, Systems Administrator Eastern Nazarene College 23 East Elm Avenue Quincy, MA 02170 [EMAIL PROTECTED] 617-745-3806 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: identity crisis of 6-STABLE in ipfw ipv6 ?
On Wed, Aug 16, 2006 at 10:57:02AM -0400, John Baldwin wrote: On Wednesday 16 August 2006 04:53, David Malone wrote: On Wed, Aug 16, 2006 at 08:13:20AM +0200, Kees Plonsz wrote: I just updated to 6-STABLE but my ipfw rules stopped working. It seems that me6 is vanished into thin air. # ipfw add 7000 allow ip from me6 to me6 ipfw: hostname ``me6'' unknown I think it was broken by some missing brackets in this commit: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/ipfw2.c#rev1.88 Can you try the patch below? If it looks good, Max or I can commit the fix. David. Note that the strcmp() != 0 doesn't need extra ()'s as != is higher than in precedence. Ditto for ret == NULL on the same line. That can be spelled safely as: if (ret == NULL strcmp(av, any) != 0) It's the precedence of vs. || that can be mistaken easily. The rule is simple: is multiplication and || is addition, with their relative precedence the same as that of their arith counterparts. However, it's usually safer to use more paretheses around them because anybody but a die-hard C freak will have trouble interpreting long chains of logical subexpressions connected by 's and ||'s, with the meaning of some of them reversed by a bang. :-) Operator Associativity - ... == !=left to right ... left to right || left to right Index: ipfw2.c === RCS file: /FreeBSD/FreeBSD-CVS/src/sbin/ipfw/ipfw2.c,v retrieving revision 1.88 diff -u -r1.88 ipfw2.c --- ipfw2.c 14 May 2006 03:53:04 - 1.88 +++ ipfw2.c 16 Aug 2006 08:50:04 - @@ -3707,10 +3707,10 @@ inet_pton(AF_INET6, host, a)) ret = add_srcip6(cmd, av); /* XXX: should check for IPv4, not !IPv6 */ - if ((ret == NULL) proto == IPPROTO_IP || strcmp(av, me) == 0 || - !inet_pton(AF_INET6, host, a)) + if ((ret == NULL) (proto == IPPROTO_IP || strcmp(av, me) == 0 || + !inet_pton(AF_INET6, host, a))) ret = add_srcip(cmd, av); - if ((ret == NULL) strcmp(av, any) != 0) + if ((ret == NULL) (strcmp(av, any) != 0)) ret = cmd; free(host); @@ -3733,10 +3733,10 @@ inet_pton(AF_INET6, host, a)) ret = add_dstip6(cmd, av); /* XXX: should check for IPv4, not !IPv6 */ - if ((ret == NULL) proto == IPPROTO_IP || strcmp(av, me) == 0 || - !inet_pton(AF_INET6, av, a)) + if ((ret == NULL) (proto == IPPROTO_IP || strcmp(av, me) == 0 || + !inet_pton(AF_INET6, av, a))) ret = add_dstip(cmd, av); - if ((ret == NULL) strcmp(av, any) != 0) + if ((ret == NULL) (strcmp(av, any) != 0)) ret = cmd; free(host); ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RocketRAID 2224
On 8/18/06, Dave Kingsley [EMAIL PROTECTED] wrote: I am attemping to use a RocketRAID 2224 8 channel card to set up a storage server. The server board is an Intel SE7230NH1-E with a P4-D 2.8GHz, 2GB RAM. FreeBSD doesn't see it at all. I've noticed that the kernel config has options built in for the RocketRAID 182x. Are there options I can add for the newer card? If so, will they work with FreeBSD 6.1 so that I can reconfigure for it rather than 6.0 that's running now? Basically we're trying to set up backups to disk with a RAID of about 4.5TB. FreeBSD has native support for the following: $whatis highpoint hptmv(4) - HighPoint RocketRAID 182x device driver rr232x(4)- HighPoint RocketRAID 232x device driver You have have a 2224 so no. You will need to use HighPoint's FreeBSD drivers. You can download everything from here: http://www.highpoint-tech.com/USA/bios_rr2224.htm While your at it update your cards BIOS (if needed) and grab a copy of CLI FreeBSD v2.2, the RAID management utility. After you download the driver and un-tar it use the rr222x-bsd-6.img file... It's designed for FreeBSD 6.0 but works perfect on FreeBSD 6.1... Follow the steps below, remember to change /dev/md0 if needed: This installs the device driver: # mdconfig -a -t vnode -f rr222x-bsd-6.img # mount /dev/md0 /mnt # cp /mnt/hptmv6-6.0.ko /boot/modules/ # echo 'hptmv6_load=yes' /boot/loader.conf This installs the console management utility: # pkg_add hptraidconf-2.2.tbz # pkg_add hotsvr-3.12.tbz That's it, after you reboot everything will be working. You should print out the pdf manual for the console management utility. If you need more help just ask... I myself have an HPT 2220. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld does nothing
Tom Hummel wrote this message on Thu, Aug 17, 2006 at 17:17 +0200: Where did bash come from? It's not part of FreeBSD; I guess you somehow replaced /bin/sh with bash. gosh, no. Bash should be located in /usr/local/bin/ and I invoke it at login for root in chase of an interactive session through ~/.cshrc. I didn't want to change root's login shell into something not part of fbsd-base. If you have bash running out of .cshrc, then that is probably your problem, as csh sources .cshrc each time it runs, so that means any scripts that are csh scripts will not function because bash will start... I added an echo to my .cshrc file: hydrogen,ttype,/home/johng,509$tail -1 .cshrc echo I am csh and I am lame and created this csh script: #!/bin/csh echo foo which results in: hydrogen,ttype,/home/johng,510$/tmp/t.csh I am csh and I am lame foo drop running bash and things will work... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The need for initialising disks before use?
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=51READY,DSC,ERROR error=40UNCORRECTABLE 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=51READY,DSC,ERROR error=40UNCORRECTABLE 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=51READY,DSC,ERROR error=40UNCORRECTABLE 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=51READY,DSC,ERROR error=40UNCORRECTABLE 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]
Re: FreeBSD boots too fast on Dell PE850
On Saturday 19 August 2006 03:12, Alan Amesbury wrote: Thanks for the feedback and discussion! Alas, in terms of network configuration, I'm just a tenant; I have no direct control over the networking gear, nor direct visibility into how the switch is configured. A couple people wrote to me directly and suggested I 'send-pr' this, so I'll do so (hopefully later today). Thanks again! -- Alan Amesbury University of Minnesota This is a really old problem, actually two. The first being the spanning tree problem where it can take a long time for it to settle and your port go into forwarding state. Adding a random sleep doesn't help because - how long do you sleep for ? How we got around this problem at various sites was, by modifying rc scripts, to check if a default gateway was configured (typical), and ping it until a response was received, or a large timeout occurred (eg. 5 minutes). That way, all other network services like nptdate, and sendmail would have a better chance of working. If your machine doesn't use a static IP, but instead dhcp, then you will need to have a long timeout/retry on the dhcp requests. The second problem we found was, various NICs would report that they were active after doing auto negotiation, but no rx packets were being passed into to the OS. Not sure if it was a hardware or driver issue, but we discovered that by forcing a packet out the NIC via the bpf interface, it would immediately start doing stuff. It was if the auto negotiation had not really completed fully until a packet was transmitted. This only occurred on certain types of NICs, the newer ones. This was a problem for us because we build something called a remote network appliance (RNA) which is basically FreeBSD on a floppy and runs a statistical lan analyser. The RNA might have many NICs in it, one with an IP, the others just connected to network segments in promiscuous mode. Our apps couldn't monitor any traffic because no packets had be sent out the interfaces. So, early in the boot process we force out a couple of Loopback packets and everything works just fine. Not sure if the second issue would be a problem for normal installations though. Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The need for initialising disks before use?
On Fri, Aug 18, 2006 at 01:41:27PM -1000, Antony Mawer wrote: 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=51READY,DSC,ERROR error=40UNCORRECTABLE 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=51READY,DSC,ERROR error=40UNCORRECTABLE 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=51READY,DSC,ERROR error=40UNCORRECTABLE 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=51READY,DSC,ERROR error=40UNCORRECTABLE 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... I really don't know. The only way I can think of to find out is to own a large number of machine and perform an experiment. We (the general computing public) don't have the kind of models needed to really say anything definitive. Drive are too darn opaque. Once I do start seeing these, is there an easy way to: a) determine what file/directory entry might be affected? Not easily, but this question has been asked and answered on the mailing lists recently (I don't remember the answer, but I think there were some ports that can help). b) dd if=/dev/zero over the affected sectors only, in order to trigger a sector remapping without nuking the whole drive You can use src/tools/tools/recover disk to refresh all of the disk except the parts that don't work and then use dd and the console error output to do the rest. 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) ??? Presumably it will be one of i, ii or a mangled superblock. I don't know how you'd tell which off the top of my head. This is one of the reasons I think Sun is on the right track with zfs's checksum everything approach. At least that way you actually know when something goes wrong. 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? The OS is generally unaware of such events except to the extent that they know a fatal read error occurred or that they read the SMART data from the drive in the case of write failures. -- Brooks pgpUCIAcpqMtN.pgp Description: PGP signature
Re: The need for initialising disks before use?
On Fri, Aug 18, 2006 at 09:52:02PM -0500, Brooks Davis wrote: On Fri, Aug 18, 2006 at 01:41:27PM -1000, Antony Mawer wrote: 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=51READY,DSC,ERROR error=40UNCORRECTABLE 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=51READY,DSC,ERROR error=40UNCORRECTABLE LBA=47702304 i have recently managed to borrow an acer pentium III 550 mhz based machine to test and use as an installation server for freebsd v6.1-release. after running a minimum (basic) installation on teh machine, which has a pair of drives (an 850 mb maxtor atapi/ide and a 1 gb fujitus atapi/ide drive that has a block of some 400-550 megabite that the bios/ms windows 2000 was not able to accessand i built my freebsd partitions/slices around .. this is why i was originally interested in this thread, so that i might get a way of refresh this disks media and possibly revover teh who media surface or find out what is going on. originally the error messages concerned only the oddly partitioned/sliced fujitsu but afte a few days it spread and as best as i can recall the machine will loose console access (and network login access as well but this could be some intermitent aspect) via sshd as soon as either of the disks are written too, in my case it seems to be access to teh swap slice as this machine has a small memory footprint, 32 megabyte untill i can canabalise another or replace the machine. i cannot use freebsd 6.1-release on any of my machines as they all have scsi drives and host with bootable cdroms but with bioses that use the old (high seirra) bootable cdrom format, software and this machine while not recent is still some 5 to 10 years newer than my own most recent hardware. stuff trimmed for brevity 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... I really don't know. The only way I can think of to find out is to own a large number of machine and perform an experiment. We (the general computing public) don't have the kind of models needed to really say anything definitive. Drive are too darn opaque. Once I do start seeing these, is there an easy way to: a) determine what file/directory entry might be affected? Not easily, but this question has been asked and answered on the mailing lists recently (I don't remember the answer, but I think there were some ports that can help). might i add that while the original question (the refreshing of the operating diskes media) has (may have) been answered, sorry i didn't follow this thread as asidiously as i should have, because the thread was only of partial interst to me, but since this post has caught my interest because my installation of freebsd on stable hardware has started to produce similare error messages i now think that the original question has morphed (as these things usually do, somewhat sadly) into something dare i say it, quiet different. i've sent Mr Mawer a post off list giving some details and depending on teh answers it might be worth while posting a bug report of sorts ??? most kind regards jonathan -- powered by .. QNX, OS9 and freeBSD -- http://caamora com au/operating system === appropriate solution in an
FreeBSD on Compaq
Hi, I obtained a Compaq(COMPAQ PROLIANT 5500) machine by chance. By the way, is possible install FreeBSD this machine? If possible, which version I try installation? Sincerely, -- Byung-Hee HWANG [EMAIL PROTECTED] You... really do... make it rain blood. -- Tomoe YUKISHIRO ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
