On Mon, Nov 24, 2003 at 06:41:01AM -0800, Carol Overes wrote:
Hi,
Thanks for your help finding ISO images for 4.7.
But does anyone know how long 4.7 will be supported
and provided with security fixes ?
I already answered that, but to repeat what I said in my previous
reply:
According to
no, i use the same cable, now i disconnect the drive ( ad2 )
and get the same errors for ad1. ad1 is on the primary controller.
ad2 was on the secondary controller. ad1 is a brand new drive.
regards Stefan
On 23 Nov 2003 17:13:47 -0500
Lowell Gilbert [EMAIL PROTECTED] wrote:
Stefan
oki, here a tail from the dmesg log
ad1s1e: hard error reading fsbn 260800575 of 130400256-130400511
(ad1s1 bn 260800575; cn 16234 tn 21 sn 42) trying PIO mode ad1:
DMA problem fallback to PIO mode ad1: DMA problem fallback to
PIO mode
ad1: DMA problem fallback to PIO mode
ad1: DMA
On Monday 24 November 2003 15:32, Mike Tancsa wrote:
The problem is that LQR is agreed to with the ERX (the PPPoE terminating
device on the other end), but it never works.
Works for me. I guess there really are many providers with misconfigured
equipment out there. Actually, I know people who
Well, the problem there is that your drive can't do UDMA at the speed it is
trying to. Replace the cable, make sure it is an 80 conductor cable
conforming to the standards for IDE cables, most specifically, it should not
be longer than 45cm.
If that doesn't help, try setting a lower UDMA mode
Are you sure you actually connect to an ERX on the other end, and its
actually negotiating LQR ? e.g. if you add LQM to the logging section, do
you see
tun0: LQM: deflink: Will send LQR every 10.00 secs
or do you see
tun0: LQM: deflink: LQR/ECHO LQR not negotiated
What do you have for your
On Monday 24 November 2003 16:46, Mike Tancsa wrote:
Are you sure you actually connect to an ERX on the other end, and its
actually negotiating LQR ? e.g. if you add LQM to the logging section, do
you see
tun0: LQM: deflink: Will send LQR every 10.00 secs
or do you see
tun0: LQM: deflink:
At 10:59 AM 24/11/2003, Michael Nottebrock wrote:
On Monday 24 November 2003 16:46, Mike Tancsa wrote:
Are you sure you actually connect to an ERX on the other end, and its
actually negotiating LQR ? e.g. if you add LQM to the logging section, do
you see
tun0: LQM: deflink: Will send LQR
hi,
sorry that i do not send more information, this not happened again :)
here a part of my dmesg bootup. i use FreeBSd 4.9 on a
HP Vectra VL400. the problem comes up first, as i add the adaptec
SCSI controller, but do not use a disk on it. and i replace both
disks. as you can see the disks are
On Monday 24 November 2003 17:07, Mike Tancsa wrote:
At 10:59 AM 24/11/2003, Michael Nottebrock wrote:
On Monday 24 November 2003 16:46, Mike Tancsa wrote:
Are you sure you actually connect to an ERX on the other end, and its
actually negotiating LQR ? e.g. if you add LQM to the logging
At 11:25 AM 24/11/2003, Michael Nottebrock wrote:
And for
sure its an ERX on the other end ?
Actually it's an NRP - it seems Cisco does a better job with their PPPoE
implementation.
OK, thanks. The problem I see is only against an ERX. So either
misconfigured ERX or something about Juniper's
I note on a 4.9-prerelease running NFS server (kernel built October 3rd) a series of
infrequent messages such as:
Nov 18 14:19:56 nas /kernel: ufs_rename: fvp == tvp (can't happen)
Nov 18 23:06:41 nas /kernel: ufs_rename: fvp == tvp (can't happen)
Nov 19 22:25:29 nas /kernel: ufs_rename: fvp ==
On Monday 24 November 2003 17:35, Mike Tancsa wrote:
given that VJ Header compression also does not play well with FreeBSD's
I am leaning to the ERX.
Right, vjcomp, I don't need to disable that here as well...
Back to the original question of how best to work around this. I will be
13 matches
Mail list logo
