On Monday 21 August 2006 23:08, Dominic Marks wrote:
> You can use device.hints(5) to do this.
>
> I have the following in mine to force a RAID card and Sound card to
> share IRQ 17.
> You need to modify it to suit your environment.
>
> hw.pci3.13.INTA.irq="17"
>
> The `13' value is the device numb
Matt Dawson wrote:
On Monday 21 August 2006 13:00, [EMAIL PROTECTED] wrote:
I can confirm the same behaviour with a ULi M1689/Newcastle Athlon64
based system running 6.1-RELEASE-p3 (i386). ad6 just detaches without
warning and it takes a reboot to bring it back. atacontrol reinit has no
effect
Patrick M. Hausen wrote:
Hi, Dominic!
On Mon, Aug 21, 2006 at 02:40:17PM +0100, Dominic Marks wrote:
hw.pci3.13.INTA.irq="17"
The `13' value is the device number, you can find this in dmesg, same
for pciN.
So I tried this:
em1: port 0x5000-0x501f
mem 0xdc18-0xdc19,0xdc10-0xd
Hi, Dominic!
On Mon, Aug 21, 2006 at 02:40:17PM +0100, Dominic Marks wrote:
> hw.pci3.13.INTA.irq="17"
>
> The `13' value is the device number, you can find this in dmesg, same
> for pciN.
So I tried this:
em1: port 0x5000-0x501f
mem 0xdc18-0xdc19,0xdc10-0xdc17 irq 17 at dev
Patrick M. Hausen wrote:
Hello!
On Mon, Aug 21, 2006 at 02:14:16PM +0100, Matt Dawson wrote:
FWIW, the problem takes *far* longer to rear its head when the SATA controller
has a PCI INT and IRQ to itself. Put a NIC onto a shared slot (a very Bad
Thing [TM] as the BIOS simply maps the INT to a
Patrick M. Hausen wrote:
Hello!
On Mon, Aug 21, 2006 at 02:14:16PM +0100, Matt Dawson wrote:
FWIW, the problem takes *far* longer to rear its head when the SATA controller
has a PCI INT and IRQ to itself. Put a NIC onto a shared slot (a very Bad
Thing [TM] as the BIOS simply maps the INT to a
Hello!
On Mon, Aug 21, 2006 at 02:14:16PM +0100, Matt Dawson wrote:
> FWIW, the problem takes *far* longer to rear its head when the SATA
> controller
> has a PCI INT and IRQ to itself. Put a NIC onto a shared slot (a very Bad
> Thing [TM] as the BIOS simply maps the INT to a single IRQ and bo
On Monday 21 August 2006 22:44, Matt Dawson wrote:
> > atacontrol detach ata3; atacontrol attach ata3 did.
>
> Yes, that is the method for a controlled remove and reattach, a la hotplug
> SATA. AIUI, though, if the drive goes AWOL on its own you need to reinit
> the channel before issuing an atacon
On Monday 21 August 2006 13:00, [EMAIL PROTECTED] wrote:
> > I can confirm the same behaviour with a ULi M1689/Newcastle Athlon64
> > based system running 6.1-RELEASE-p3 (i386). ad6 just detaches without
> > warning and it takes a reboot to bring it back. atacontrol reinit has no
> > effect. Tried
Hi!
On Sun, Aug 20, 2006 at 01:38:55PM +0100, Matt Dawson wrote:
> I can confirm the same behaviour with a ULi M1689/Newcastle Athlon64 based
> system running 6.1-RELEASE-p3 (i386). ad6 just detaches without warning and
> it takes a reboot to bring it back. atacontrol reinit has no effect. Trie
On Mon, Aug 21, 2006 at 04:03:47AM +0200, Konstantin Saurbier wrote:
> Am 20.08.2006 um 18:20 schrieb Greg Byshenk:
> >What is different is that this was with a 3Ware RAID controller --
> >which made removing/raconfiguring/rebuilding much easier -- but I was
> >seeing the exact same errors.
> No
Hi, all!
On Mon, Aug 21, 2006 at 04:22:06PM +0900, Pyun YongHyeon wrote:
> Several users reported em(4) watchdog errors but I couldn't reproduce
> it on my system. A blind patch posted to net ML and I'd like to hear
> success/failure report.
>
> See http://lists.freebsd.org/pipermail/freebsd-net
Hi!
Am 21.08.2006 um 09:10 schrieb Patrick M. Hausen:
Hi, all!
On Mon, Aug 21, 2006 at 04:03:47AM +0200, Konstantin Saurbier wrote:
This errors are not driver or OS dependent such as they appear on
FreeBSD as well on different Linux distros.
Since not all controllers suffering of these error
On Mon, Aug 21, 2006 at 09:10:53AM +0200, Patrick M. Hausen wrote:
> Hi, all!
>
> On Mon, Aug 21, 2006 at 04:03:47AM +0200, Konstantin Saurbier wrote:
>
> > This errors are not driver or OS dependent such as they appear on
> > FreeBSD as well on different Linux distros.
> > Since not all
Hi, all!
On Mon, Aug 21, 2006 at 04:03:47AM +0200, Konstantin Saurbier wrote:
> This errors are not driver or OS dependent such as they appear on
> FreeBSD as well on different Linux distros.
> Since not all controllers suffering of these errors it is maybe
> depending on the firmware or boar
Am 20.08.2006 um 18:20 schrieb Greg Byshenk:
On Sun, Aug 20, 2006 at 01:38:55PM +0100, Matt Dawson wrote:
On Sunday 20 August 2006 13:00, [EMAIL PROTECTED]
wrote:
Do you mean different type of cables, or just another piece? I can't
change cables by myself, servers are dedicated from provid
Miroslav Lachman wrote:
I upgraded to RELENG_6, changed all HW (whole servers and changed
Seagate HHDs to Samsung so every piece of HW is different from time of
my first post), but after one week I got the same error and system
reboot today:
Aug 19 15:11:20 track ntpd[456]: kernel time sync en
Greg Byshenk wrote:
On Sun, Aug 20, 2006 at 07:51:29PM +0200, Miroslav Lachman wrote:
Greg Byshenk wrote:
[...]
This happened four times (with the same errors that have been discussed
here), running 6.1 STABLE as of June 22. Before attempting to RMA the
drives, I tried an updated kernel,
Hello!
On Sat, 19 Aug 2006, Miroslav Lachman wrote:
Aug 19 15:11:20 track ntpd[456]: kernel time sync enabled 2001
Aug 19 15:15:47 track kernel: ad6: FAILURE - device detached
Aug 19 15:15:47 track kernel: subdisk6: detached
Aug 19 15:15:47 track kernel: ad6: detached
I think that's a shame
On Sun, Aug 20, 2006 at 07:51:29PM +0200, Miroslav Lachman wrote:
> Greg Byshenk wrote:
[...]
> >This happened four times (with the same errors that have been discussed
> >here), running 6.1 STABLE as of June 22. Before attempting to RMA the
> >drives, I tried an updated kernel, 6.1 STABLE as of
Greg Byshenk wrote:
[...]
I am not sure if it is related, but... I experienced a similar sort of
problem, although the details in my case are quite different.
What was similar was that I would "lose" two ATA drives from an array,
inexplicably. Reconfiguring the same drives and rebuilding would
On Sun, Aug 20, 2006 at 01:38:55PM +0100, Matt Dawson wrote:
> On Sunday 20 August 2006 13:00, [EMAIL PROTECTED] wrote:
> > Do you mean different type of cables, or just another piece? I can't
> > change cables by myself, servers are dedicated from provider, but as I
> > can saw, they picked whole
On Sunday 20 August 2006 13:00, [EMAIL PROTECTED] wrote:
> Do you mean different type of cables, or just another piece? I can't
> change cables by myself, servers are dedicated from provider, but as I
> can saw, they picked whole new machine from their HW storage and put new
> Samsung disk drives i
Igor Robul wrote:
On Sat, Aug 19, 2006 at 04:39:55PM +0200, Miroslav Lachman wrote:
I upgraded to RELENG_6, changed all HW (whole servers and changed
Seagate HHDs to Samsung so every piece of HW is different from time of
my first post), but after one week I got the same error and system
Jus
On Sat, Aug 19, 2006 at 04:39:55PM +0200, Miroslav Lachman wrote:
> I upgraded to RELENG_6, changed all HW (whole servers and changed
> Seagate HHDs to Samsung so every piece of HW is different from time of
> my first post), but after one week I got the same error and system
Just a try - have yo
Johan Ström wrote:
[...]
Usually when the box has been rebooted before the failed component has
been rebuilt automaticly.. Solved with:
$ gmirror forget
$ gmirror insert gm0s1 ad4s1
And now its rebuilding ad4 again...
Any new hints? Should i try RELENG_6 instead?
I upgraded to RELENG_6, ch
On Jul 28, 2006, at 13:15 , Johan Ström wrote:
On 17 jul 2006, at 17.40, Miroslav Lachman wrote:
Mike Tancsa wrote:
[..]
Install the smartmontools from
/usr/ports/sysutils/smartmontools/
and post the output of
smartctl -a /dev/ad8
smartmontools was previously installed and running as daem
Johan Ström wrote:
[...]
On 17 jul 2006, at 17.40, Miroslav Lachman wrote:
Mike Tancsa wrote:
[..]
Install the smartmontools from
/usr/ports/sysutils/smartmontools/
and post the output of
smartctl -a /dev/ad8
smartmontools was previously installed and running as daemon without
any bad re
On 17 jul 2006, at 17.40, Miroslav Lachman wrote:
Mike Tancsa wrote:
[..]
Install the smartmontools from
/usr/ports/sysutils/smartmontools/
and post the output of
smartctl -a /dev/ad8
smartmontools was previously installed and running as daemon
without any bad reports.
I can not run "smart
Mike Tancsa wrote:
[..]
Install the smartmontools from
/usr/ports/sysutils/smartmontools/
and post the output of
smartctl -a /dev/ad8
smartmontools was previously installed and running as daemon without any
bad reports.
I can not run "smartctl -a /dev/ad8" now, because my server housing
pro
At 11:02 AM 17/07/2006, Johan Ström wrote:
On 17 jul 2006, at 16.51, Mike Tancsa wrote:
This at least rules out the disks being bad for the most part. It
still could be bad cables, but if you changed those out than its
doubtful. Perhaps try updating to RELENG_6 ? If its a gmirror
issue, I th
On 17 jul 2006, at 16.51, Mike Tancsa wrote:
At 05:59 AM 17/07/2006, Johan Ström wrote:
On 17 jul 2006, at 00.53, Mike Tancsa wrote:
At 03:02 PM 14/07/2006, Miroslav Lachman wrote:
After reboot (command reboot), system boot up with both disks
attached and start autosynchronization. I do
At 05:59 AM 17/07/2006, Johan Ström wrote:
On 17 jul 2006, at 00.53, Mike Tancsa wrote:
At 03:02 PM 14/07/2006, Miroslav Lachman wrote:
After reboot (command reboot), system boot up with both disks
attached and start autosynchronization. I do not know, if this is
hw or sw error, I got
Ins
On 17 jul 2006, at 00.53, Mike Tancsa wrote:
At 03:02 PM 14/07/2006, Miroslav Lachman wrote:
After reboot (command reboot), system boot up with both disks
attached and start autosynchronization. I do not know, if this is
hw or sw error, I got
Install the smartmontools from
/usr/ports/s
At 03:02 PM 14/07/2006, Miroslav Lachman wrote:
After reboot (command reboot), system boot up with both disks
attached and start autosynchronization. I do not know, if this is hw
or sw error, I got
Install the smartmontools from
/usr/ports/sysutils/smartmontools/
and post the output of
sma
Robert Watson wrote:
I don't have a whole lot to add to this thread, but have changed the
subject to make sure that the right people are reading this. This is
likely either a hardware problem (motherboard/cable/drive) or driver
problem. GEOM and the mirror driver seems to be behaving as desir
On 13 jul 2006, at 14.26, Robert Watson wrote:
On Thu, 13 Jul 2006, Johan Ström wrote:
And now again... raid gone degraded only 2 days after reboot!
Jul 12 22:22:50 elfi kernel: ad4: FAILURE - device detached
Jul 12 22:22:50 elfi kernel: subdisk4: detached
Jul 12 22:22:50 elfi kernel: ad4:
On Thu, 13 Jul 2006, Johan Ström wrote:
And now again... raid gone degraded only 2 days after reboot!
Jul 12 22:22:50 elfi kernel: ad4: FAILURE - device detached
Jul 12 22:22:50 elfi kernel: subdisk4: detached
Jul 12 22:22:50 elfi kernel: ad4: detached
Jul 12 22:22:50 elfi kernel: GEOM_MIRROR:
38 matches
Mail list logo
