On Tuesday 05 September 2006 03:16, Indigo 23 wrote:
> Thanks for the reply. I already tried that, but unfortunetly the same
> thing happens :(
> Any other suggestions?
Maybe you want to try my new Giant free USB driver:
#
# How to install the new USB driver:
#
#
# First get all the sources
#
Hi, all!
On Fri, Sep 01, 2006 at 11:15:37AM -0600, Scott Long wrote:
> It is very arguably a bug in the LSI firmware if it is actually dumping
> its cache when a PCI reset occurs, especially if a battery unit is
> present. However, I seriously doubt that you will get anyone at LSI to
> listen to
On 2006-09-04 22:57, Sam Leffler wrote:
> Volker wrote:
>> ifconfig ath0 says:
>> ath0: flags=8843 mtu 2290
>> ether 00:09:5b:89:7d:1f
>> media: IEEE 802.11 Wireless Ethernet autoselect
>> status: no carrier
>> ssid vtec channel 9
>> authmode WPA privacy MIXE
Hi, all!
> > Also, check the cache
> > setting on the drives itself. Maybe the drives are loosing power or
> > getting reset while data is in their cache.
>
> I'm starting to suspect something like this. The controller's setting
> for the individual drives' caches is "OFF". But these (Seagate ST3
Hi, all!
Here's the preliminary results:
- Disk write cache off by the means of:
megarc -pSetCache -WCE0 -SaveCacheSetting -ch0 -id$drive -a0
- Controller cache policy: write through (megamgr or BIOS setup)
- Softupdates: enabled, FreeBSD 6-STABLE
System is stable, so far. I will put it back
Thanks for that excellent suggestion. It worked perfectly. I just
have a few questions.
1) Any idea when this will be imported in to RELENG_6?
2) I have to do this everytime I update my sources, correct?
3) This is relatively stable, correct? (I did test it out a bit, but
of course not thoroug
On Tuesday 05 September 2006 13:28, Indigo 23 wrote:
> Thanks for that excellent suggestion. It worked perfectly. I just
> have a few questions.
>
> 1) Any idea when this will be imported in to RELENG_6?
I don't know. If I am right, you will see my driver in freebsd-current some
time after Chri
Hi all,
While trying to update ports for FreeBSD 6.1-STABLE using this command:
/usr/local/sbin/portsdb -Uu
I got the following error (please see below for the process leading up
to this):
Updating the ports index ... Generating INDEX.tmp - please
wait.."Makefile", lin
e 33: Could not find
Ron Tarrant wrote:
Hi all,
While trying to update ports for FreeBSD 6.1-STABLE using this command:
/usr/local/sbin/portsdb -Uu
I got the following error (please see below for the process leading up
to this):
Updating the ports index ... Generating INDEX.tmp - please
wait.."Makefile", lin
e
On Tue, 05 Sep 2006 09:25:38 -0400, Ron Tarrant <[EMAIL PROTECTED]>
wrote:
> At first, I commented out all the ports for languages I don't understand
> such as Russian, Japanese, etc. But I got a similar error, so I
> commented out all the individual ports and uncommented ports-all to do a
> co
On Tue, 5 Sep 2006 11:01:39 -0300, Ricardo Nabinger Sanchez
<[EMAIL PROTECTED]> wrote:
> On Tue, 05 Sep 2006 09:25:38 -0400, Ron Tarrant <[EMAIL PROTECTED]>
> wrote:
>
> > At first, I commented out all the ports for languages I don't
> > understand such as Russian, Japanese, etc. But I got a simi
Ricardo Nabinger Sanchez wrote:
On Tue, 5 Sep 2006 11:01:39 -0300, Ricardo Nabinger Sanchez
<[EMAIL PROTECTED]> wrote:
On Tue, 05 Sep 2006 09:25:38 -0400, Ron Tarrant <[EMAIL PROTECTED]>
wrote:
At first, I commented out all the ports for languages I don't
understand such as Russian, J
Chris Jones wrote:
Instead of regenerating the INDEX, why not just download it?
# cd /usr/ports
# make fetchindex
Regards,
Chris Jones
Thanks for the reply, Chris.
Yup, good idea. I did this and found out that INDEX-6 was already
up-to-date. Could this be why index generation failed?
-Ron
Hi,
> [..]
> At first, I commented out all the ports for languages I don't understand
> such as Russian, Japanese, etc. But I got a similar error, so I
> commented out all the individual ports and uncommented ports-all to do a
> complete job of it. That's when I ran portsdb -Uu and got the abov
Ron Tarrant wrote:
Chris Jones wrote:
Instead of regenerating the INDEX, why not just download it?
# cd /usr/ports
# make fetchindex
Regards,
Chris Jones
Thanks for the reply, Chris.
Yup, good idea. I did this and found out that INDEX-6 was already
up-to-date. Could this be why index gen
On 8/30/06, Yoshihiro Ota <[EMAIL PROTECTED]> wrote:
It may be a bit early but I switched to RELENG_6 fot that reason.
Me too, on a couple of "not really production" machines. I generally
switch a couple more "production but not critical" machines over once
the RE cycle begins, which is why I w
On Tue, Sep 05, 2006 at 09:25:38AM -0400, Ron Tarrant wrote:
> Updating the ports index ... Generating INDEX.tmp - please
> wait.."Makefile", lin
> e 33: Could not find
> /usr/ports/japanese/gnomelibs/../../x11/gnomelibs/Makefile
Why not?
> have a complete and up-to-date ports collection. (IN
Wolfgang Zenker wrote:
just to make sure: You did run cvsup after uncommenting ports-all and
before running portsdb -Uu, right?
Thanks for the reply, Wolfgang.
I'm pretty sure I did. That was last night and I have a vague memory of
doing it. That tty is tied up right now, so I can't chec
Chris Jones wrote:
Yup, good idea. I did this and found out that INDEX-6 was already
up-to-date. Could this be why index generation failed?
Shouldn't have mattered... all that would happen is the generated
INDEX would've overwritten the downloaded one.
Hmm... Very curious.
Thanks.
This server was in production and rock steady with 4.10-STABLE for years.
Before moving it to a colo center, I took it offline and did a clean
install of 6.1, cvsup'd to STABLE on 8/30/06 and then installed the latest
stable versions of all the applications and mods.
It's now back in production a
On Tue, 5 Sep 2006, Ron Tarrant wrote:
Hi all,
While trying to update ports for FreeBSD 6.1-STABLE using this command:
/usr/local/sbin/portsdb -Uu
I've seen errors similar to yours when your Mk files are out of
date with the rest of your ports tree. As root:
# cd /usr/ports/Mk
# cvs -R
On Tue, Sep 05, 2006, [EMAIL PROTECTED] wrote:
> It's now back in production and for no cause that I can find, it reboots
> itself roughly twice a day. Nothing in the syslog or console log [...]
Try setting `dumpdev' in your rc.conf to the swap device. After the
machine reboots, you might get a
Jack Vogel wrote:
> On 8/30/06, Danny Braniss <[EMAIL PROTECTED]> wrote:
>>
>> ever since 6.1 I've seen fluctuations in the performance of
>> the em (Intel(R) PRO/1000 Gigabit Ethernet).
>>
>> motherboard OBN (On Board NIC)
>>
Hi Kris,
Thanks for the reply...
Kris Kennaway wrote:
On Tue, Sep 05, 2006 at 09:25:38AM -0400, Ron Tarrant wrote:
Updating the ports index ... Generating INDEX.tmp - please
wait.."Makefile", lin
e 33: Could not find
/usr/ports/japanese/gnomelibs/../../x11/gnomelibs/Makefile
Why no
Updated my Athlon-xp 6-stable system last night, got an em watchdog
timeout for the first time a few hours later, during a fairly
high-traffic period. System is UP but does have device apic in
the config. Any chance this is the recent race condition?
Workaround? ifconfig em0 down, ifconfig em0 u
On Tue, Sep 05, 2006 at 10:55:04AM -0400, [EMAIL PROTECTED] wrote:
>
> This server was in production and rock steady with 4.10-STABLE for years.
> Before moving it to a colo center, I took it offline and did a clean
> install of 6.1, cvsup'd to STABLE on 8/30/06 and then installed the latest
> sta
Thanks again for the help. If you require beta testers, just e-mail
me to let me know.
On 9/5/06, Hans Petter Selasky <[EMAIL PROTECTED]> wrote:
On Tuesday 05 September 2006 13:28, Indigo 23 wrote:
> Thanks for that excellent suggestion. It worked perfectly. I just
> have a few questions.
>
>
Hello,
I get these errors a lot.
Sep 5 11:55:12 ronald kernel: em0: watchdog timeout -- resetting
Sep 5 11:55:12 ronald kernel: em0: link state changed to DOWN
Sep 5 11:55:14 ronald kernel: em0: link state changed to UP
Sep 5 12:00:37 ronald kernel: em0: watchdog timeout -- resetting
Sep 5
You recently sent mail to [EMAIL PROTECTED]
The e-mail address, [EMAIL PROTECTED], has been changed.
The new e-mail address is [EMAIL PROTECTED]
Your mail was forwarded to the new address; you do not need to resend it.
This message was sent automatically. No reply is necessary.
On Tuesday 05 September 2006 14:52, Ronald Klop wrote:
> Hello,
>
> I get these errors a lot.
>
> Sep 5 11:55:12 ronald kernel: em0: watchdog timeout -- resetting
> Sep 5 11:55:12 ronald kernel: em0: link state changed to DOWN
> Sep 5 11:55:14 ronald kernel: em0: link state changed to UP
> Sep
Ricardo Nabinger Sanchez wrote:
IIRC, you must have all the ports (ports-all in your config file) in order
to generate an INDEX, as it will fail otherwise.
Yeah, when I realized that I interrupted the cvsup command, edited
ports-supfile to change it to ports-all, then reran cvsup. Perhaps
Wolfgang Zenker wrote:
just to make sure: You did run cvsup after uncommenting ports-all and
before running portsdb -Uu, right?
Yes. I double-checked the command history and I definitely did.
-Ron T.
--
Ron Tarrant
Blog:http://www.writingup.com/blog/phpgtk2";>PHP-Gtk2
___
Kris Kennaway wrote:
This makes me think that you didn't re-run cvsup since your "similar
error" is precisely what you'd expect if you didn't have anything in
japanese/.
It's there in my command history twice with an ee ports-supfile between
the two occurances of cvsup. BTW, this is the ex
Hi Daniel,
Welcome to the discussion.
Daniel Eischen wrote:
I've seen errors similar to yours when your Mk files are out of
date with the rest of your ports tree. As root:
# cd /usr/ports/Mk
# cvs -R update -P -d
I'm assuming that the rest of your ports tree has also been
updated accord
> Jack Vogel wrote:
> > On 8/30/06, Danny Braniss <[EMAIL PROTECTED]> wrote:
> >>
> >> ever since 6.1 I've seen fluctuations in the performance of
> >> the em (Intel(R) PRO/1000 Gigabit Ethernet).
> >>
> >> motherboard OBN (On Board NIC)
> >>
In my kernel config, I have
options FAST_IPSEC
device padlock
device crypto
which enables the crypto acceleration in VIA C3 and C7 CPUs. IPSEC
with static rijndael-cbc keys of length 128, 192, and 256 makes use
of the acceleration when sysctl net.inet.ipsec.crypto_support=1;
- so far
On Wed, Sep 06, 2006 at 08:29:13AM +0200, Adrian Steinmann wrote:
> In my kernel config, I have
>
> options FAST_IPSEC
> device padlock
> device crypto
>
> which enables the crypto acceleration in VIA C3 and C7 CPUs. IPSEC
> with static rijndael-cbc keys of length 128, 192, and 256 m
37 matches
Mail list logo
