Re: Old Computer + New HD
If I remember correctly, FreeBSD (itself) doesn't use information from the BIOS. Frees should be able to see the entire HDD. If you get geometry warnings when you attempt to slice the drive, use an hdd utility to give you the correct geometry. You may want to compare my suggestion with other suggestions or feedback. I hope that helps you. - All incoming attachments get deleted. Have a nice day. - - Original Message - From: "fallenbr" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, November 09, 2003 12:42 AM Subject: Old Computer + New HD Hi, I need to use an 80GB hard disk on my old computer, which can only detect HDs smaller than 8GB. Does anyone have any advice? How about using one of these IDE to USB racks from ViPower (www.vipower.com)? Do they work on FreeBSD? If so, will my HD work fine with it? Thanks! --- Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - É grátis! http://antipopup.uol.com.br ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 4.8-P10 Mouse doesn't move in the console or XFree86
Problem found. Update posted to: http://69.3.136.141/freebsd/usb_mouse.txt This case/instance is considered closed; --bum chipset/hardware to blame. - All incoming attachments get deleted. Have a nice day. - - Original Message - From: "nw1" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, September 28, 2003 12:51 PM Subject: Re: FreeBSD 4.8-P10 --Mouse doesn't move in the console or XFree86-- > Alex: please see the update/corrections to this post at > http://69.3.136.141/freebsd/usb_mouse.txt > > - Original Message - > From: "Alex de Kruijff" <[EMAIL PROTECTED]> > To: "nw1" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Sunday, September 28, 2003 1:44 PM > Subject: Re: FreeBSD 4.8-P10 --Mouse doesn't move in the console or XFree86-- > > > > On Sun, Sep 28, 2003 at 07:41:04AM -0400, nw1 wrote: > > > Neither mouse will work in the console or in XFree86. > > > > > > Gigabyte GA-6BXDS = main board > > > BIOS= AWARD (2A69KG01) ver. 4.51PG > > > > > > In the PCI/ISA section of the BIOS, a USB setting of: "Assign IRQ For USB: > > > Enabled" > (is > > > set) > > > There is also a "USB Keyboard Support" setting within the BIOS's "INTERGRATED > > > PEROPHERALS" section; I have tried this setting to both "Enabled and Disabled". > > > > > > There aren't any other USB settings in this BIOS. > > > > > > We are using these devices that are known working devices. > > > Mouse-1 is: Logitech | model: M-BD58 | optical corded wheel > > > Mouse-2 is: Logitech | model: M-RM67A | Optical cordless wheel > > > > > > Our Kernel: > > > # USB support > > > device uhci# UHCI PCI->USB interface > > > device usb # USB Bus (required) > > > device ums # Mouse > > > pseudo-device ether # Ethernet support > > > > > > Our /etc/rc.conf: > > > # grep -i mouse /etc/rc.conf > > > moused_enable="YES" > > > moused_port="/dev/ums0" > > > # grep -i usb /etc/rc.conf > > > usbd_enable="YES" > > > > > > Our /dev: > > > ls -l /dev | grep -i ums > > > crw-rw 1 root operator 111, 0 Sep 27 13:16 ums0 > > > > > > dmesg reports: > > > # dmesg | grep -i usb > > > uhci0: port 0xa000-0xa01f irq 10 at > > > device > 7.2 > > > on pci0 > > > usb0: on uhci0 > > > usb0: USB revision 1.0 > > > ums0: Logitech USB Mouse, rev 1.10/6.10, addr 2, iclass 3/1 > > > > > > Upon booting into the OS, using the above BIOS, and other settings --with either > > > of > the > > > above devices; the mouse is seen on screen, but it refuse to respond while moving the > > > hand-held device. Should we unplug one mouse (from either usb port) to test the other > > > mouse, we receive the following on-screen message(s), respectively of the motherboards > USB > > > port we were using: > > > > > > uhub0: device problem, disabling port 2 > > > uhub0: device problem, disabling port 1 > > > > > > When we plug the devices back in to either of the motherboards mouse ports, > > > there's no > > > indication at all, from the OS, that a USB device was attached. > > > > > > Reminder: these devices are in perfect working order. > > > > It seems to be in order. As i see it thare are two posibilties. 1) Your > > mouse isn't supported or 2) There is a (new) bug in the system. > > > > Did it work on previous version of FreeBSD? > > > > -- > > Alex > > > > Articles based on solutions that I use: > > http://www.kruijff.org/alex/index.php?dir=docs/FreeBSD/ > > ___ > > [EMAIL PROTECTED] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fw: Are threads Being filtered and/ or deleted from the archives?
I found the thread I was speaking of, but it seems a bit complex for a person who doesn't participate on the list ti find a particular thread or item. First instinct would be for a user to use the search page; that search page won't return, in particular, the thread I mentioned here. In order for me to find the thread I had to claw my way to: http://lists.freebsd.org/pipermail/freebsd-questions/2003-November/thread.html. If anyone knows of an easier way to search for an entire thread, please respond. Respectfully yours, nw1 - All incoming attachments get deleted. Have a nice day. - - Original Message - From: "nw1" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 06, 2003 4:39 PM Subject: Are threads Being filtered and/ or deleted from the archives? > Sorry to have to post this to the community at large, but the list maintainer hasn't > gotten back to me on other issues. With respect to the initial thread = Subject: > Re: Overheating attributed to Freebsd --sysctlvariablesnotavailable-- > > Any Idea why I'm not able to find this full thread in the archives? I need an AMD > representative to view this thread and it doesn't seem to be available from > beginning to > end. I can only find the last RE: from this week. I hope they aren't filtering out > threads that have a valid topic/concern. > > > - > All incoming attachments get deleted. > Have a nice day. > - > - Original Message - > From: "Guy Van Sanden" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, November 06, 2003 3:17 AM > Subject: Re: Overheating attributed to Freebsd --sysctlvariablesnotavailable-- > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Are threads Being filtered and/ or deleted from the archives?
Sorry to have to post this to the community at large, but the list maintainer hasn't gotten back to me on other issues. With respect to the initial thread = Subject: Re: Overheating attributed to Freebsd --sysctlvariablesnotavailable-- Any Idea why I'm not able to find this full thread in the archives? I need an AMD representative to view this thread and it doesn't seem to be available from beginning to end. I can only find the last RE: from this week. I hope they aren't filtering out threads that have a valid topic/concern. - All incoming attachments get deleted. Have a nice day. - - Original Message - From: "Guy Van Sanden" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 06, 2003 3:17 AM Subject: Re: Overheating attributed to Freebsd --sysctlvariablesnotavailable-- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overheating attributed to Freebsd --sysctl variables not available--
Page updated--> http://69.3.136.141/freebsd/installation/sysctl_variables_missing One (1) question is still outstanding ... Yes="I'm still researching this." - All incoming attachments get deleted. Have a nice day. - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overheating attributed to Freebsd --sysctl variables not available--
Jud, (see below) - Original Message - From: "Jud" <[EMAIL PROTECTED]> To: "nw1" <[EMAIL PROTECTED]> Cc: "freebsd-questions" <[EMAIL PROTECTED]> Sent: Tuesday, November 04, 2003 3:17 PM Subject: Re: Overheating attributed to Freebsd --sysctl variablesnotavailable-- > > On Tue, 4 Nov 2003 14:05:02 -0500, "nw1" <[EMAIL PROTECTED]> said: > [snip] > > > > I'm interested in those missing sysctl variables I posted @ > > > > http://69.3.136.141/freebsd/installation/sysctl_variables_missing. > > > > Using a Third party > > > > application/script to fix something that was natively working or under > > > > control, I don't > > > > think, is the way to go and causes another level of complexity. > [snip] > > No problem, I am interested in any and all *sane/reasonable feedback. I > > haven't been to > > much a fan of using third party applications to fix something the > > original code or > > hardware should be able to handle. > > FVCool isn't a "third party application" as I understand the term. > Perhaps a portion of the README file will make things clearer: I understand better now (FVCool). Thanks for taking the time to explain that FVCool is not a "third party application". I'm still questioning the difference in behavior --not only between the two (2) OS's when idling, --overheating in FreeBSD, and *not overheating in the non FreeBSD OS. whatsoever. > > "As is well known AMD's Athlon/Duron is a 'hot' CPU. It really produces > a lot of heat. This is mainly because it consumes a lot of electric > power. However, there is an another reason: Generally CPU goes into > power-save mode when it is in the idle state, but in almost all the > mother boards this is prohibited in the case of Athlon/Duron mother > boards in their original BIOS settings. This software changes the PCI > configuration data of the chipset (north bridge), and allow Athlon/Duron > to go into power-save mode. The principle is very simple if you have > information. Actually, you can do exactly the same thing as this > software > manually by using the 'pciconf' command in FreeBSD. > > "Why mother board vendors release their products with such BIOS > settings? What's the reason? > Well, there is a reason: There is a possibility to get the system > unstable > and/or even to hang or crash the system. Therefore, this software is > somewhat dangerous in this respect, and I will not take any > responsibilities for problems caused by using this software. Please > check the original Martin Peters's VCool web site for learning more of > technical details: > > http://vcool.occludo.net/"; > > So what FVCool does is utilize the 'pciconf' command to encourage AMD > CPUs to go into power-save mode when idle, a function most motherboard > manufacturers turn off for the stability reasons mentioned by FVCool's > author. As the documentation says, you can manually make these changes > with the 'pciconf' command, but why not save typing by installing the > port and running the 'fvcool' command, or run it automatically with a > script? > > Based on the names of the sysctls you're after, I'd speculate they may > operate in much (or even exactly) the same way. That is why I wondered, > in response to your advice to Paul Mather, whether those sysctl settings > would work with Intel CPUs. My suggestion to *Paul Mather was in fact a blind suggestion only based on the settings to lower the usage of the cpu and not raise; had it been the other way around, I'm not sure I would have recommended he set those knobs to '1'. The following fact/issue, i think, still remains outstanding; Using the setup I originally posted, we can do somethings within the non FreeBSD OS that will rival a looping 'make buildworld | buildkernel, utilizing both cpu's for encoding purposes while playing a quake3, utII game and the like, never overheating or exhibit any instability. Please don't take that above statement as a "this OS is better than your OS". What I've understood from this particular posting is this: the motherboards used for the AMD Athlon/Duron(s) have a default BIOS setting --not allowing the processors to go into 'Power Saving Mode' --while intel based --default BIOS settings: *do allow 'Power Saving Mode' for the processor(s). y/n? That seems to be just a bit disturbing. If we could for the purposes of this paragraph alone, suspend the notion of *over heating while idling*... As someone stated earlier in the thread, what about these
Re: Overheating attributed to Freebsd --sysctl variablesnotavailable--
annotated below
- Original Message -
From: "Technical Director" <[EMAIL PROTECTED]>
To: "Paul Mather" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, November 04, 2003 12:32 PM
Subject: Re: Overheating attributed to Freebsd --sysctl variablesnotavailable--
>
> > => I doubt hardware manufactuers put out equipment that can't run at 100% at
> > => least.
> >
> > FWIW, I doubt the accuracy of that last paragraph, and don't think
> > this is "so seemingly far fetched" at all. :-)
>
> Considering the high demand for consumer's purchasing 'their' products, a
> mishap like "My server can't run at high cpu due to it crashing" is part
> and parcel to shooting yourself in the foot as a manufactuer.
I'm not sure if your addressing the original poster of this thread (me) or Paul, who
has a
similar problem.
>
> If you buy a MB/PROC that cooks just by operating as a server, which in
> most cases what FreeBSD will be used for, and you know that it 'may'
> crash or lockup due to heat, don't use FreeBSD.
>
> - or -
>
> Buy hardware that won't cook out.
>
I disagree with both of your suggestions above.
Just dropping an item, in this case the OS, because its contributing to a specific
problem
is not my idea of building or refining. Up until this point, I thought it was more an
AMD
issue until I heard from *Paul Mather --who uses intel based hardware. Paul Mathers'
issue, with his *laptop seems to be more severe than my overheating with the *server.
Yes = there are some tricks more knowledgable people in the community can do to work
around issues such as this, but I'm hoping to bring the issue to the attention of
whomever
needs to see this in order to get a permenant fix. Having to set the following to '0':
machdep.apm_suspend_delay: 0
machdep.apm_standby_delay: 0
just for the machine to *not overheat while idling --doesn't seem correct.
The issue at hand may very well be explainable in its current state, but after hearing
from *Paul Mather and working closely with a lead tech @ AMD and Tyan; I'm confident
I'm
in one of the correct forum to discuss this.
Personally; I shouldn't have to buy my way out of this problem, and I will not leave
FreeBSD for another OS becaue of this. :-) Lets find out what we can do to remedy this
within FreeBSD instead of pushing people away from the project.
> R.
>
> PS
>
> Have you both tried to run 4.#-[CURRENT/STABLE/RELEASE] to see if the
> problem goes away?
>
> > I have a related problem. In my case, it's a borrowed laptop on which
> > I installed FreeBSD 5.1-CURRENT (quite a while ago, but last
> > {build,install}{kernel,world} was circa July 2003). Also installed on
> > the system is Windows 2000 Professional. The related problem I have
> > is that I can fairly easily get the laptop to power off due to
> > thermally-initiated shutdown using FreeBSD (complete with "current
> > temperature has exceeded system limits" type messages on the console
> > beforehand), but can't seem to do so via Win2K. :-(
> >
> > Now I know that in a sense this is apples and oranges, because I don't
> > do precisely the same things under both operating systems. But, it
> > seems that high-CPU/system activity under FreeBSD will ultimately lead
> > to a thermal shutdown, but not on Win2K (no so far as I've been able
> > to manage, anyway). This is inconvenient, to say the least. For
> > example, a FreeBSD buildworld or buildkernel will not complete; it'll
> > get part way through before the machine becomes too hot and shuts
> > itself down. Similarly, building "big" ports like Mozilla won't
> > complete, which makes portupgrade a bit of fun. Needless to say, this
> > system doesn't get updated much. :-)
> >
> > Now I'm not saying the machine doesn't become physically hot when
> > running Win2K, too. It does (e.g., when playing CPU-intensive games,
> > etc.). But somehow, Win2K is able to manage things so that the system
> > does not become so hot that the shutdown kicks in.
> >
> > So, I'm wondering if there's some sysctl or other knob that can be set
> > in FreeBSD that will ameliorate this problem. (I thought
> > laptop/mobile CPUs generally were able to step down to lower clock
> > speeds to conserve power/run cooler, for example.) If I could do
> > system rebuilds and port builds without having to restart that'd be a
> > big improvement! :-)
> >
> > Unlike the original poster, this is an Intel-based system, not Athlon.
> > It's a Gateway Solo 450 laptop. If I didn't know better, I'd think
> > that Gateway "engineered" (pah!) this system so it would run Windows
> > "okay" and that's it as far as they're concerned. >;-) FWIW, attached
> > at the end of this message is a copy of /var/run/dmesg.boot in case
> > anyone can suggest something to help.
> >
> > Cheers,
> >
> > Paul.
> >
> > PS: I'm glad I'm only borrowing this laptop and didn't buy it!! The
> > owner of the laptop only uses Windows, so this is only a problem for
> > me running FreeBSD.
> >
> > e-mail: [E
Re: Overheating attributed to Freebsd --sysctl variablesnotavailable--
Paul mather,
Thanks for your response ...
See comments below (annotated)
- Original Message -
From: "Paul Mather" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 04, 2003 9:45 AM
Subject: Re: Overheating attributed to Freebsd --sysctl variablesnotavailable--
> On Mon, 3 Nov 2003 21:07:45 -0700 (MST), Technical Director <[EMAIL PROTECTED]>
wrote:
>
> => Forgive me for saying:
> =>
> => If this system is borked with FreeBSD due to the cpu's not cycling
> => 'down', then use a different operating system. FreeBSD is not responsible
> => for your trouble if you can solve the problem by moving on. Doing so and
> => solving the problem is more important than holding the OS and the
> => contributors to it accountable to something so seemingly far fetched.
> =>
> => One way to test overall integrity of your hardware is to boot to bios and
> => leave it. Does it bake out on you? Then there is definitely something
> => wrong with your hardware, perhaps a fan is spinning less rpms than when
> => new.
> =>
> => In my humble opinion this is probably not associated with the OS, but,
> => that doesn't solve 'your' problem. So besides seeing it for myself I can't
> => see an absolute need to use FreeBSD, in your words the problem, and not
> => use some other [$]NIX.
> =>
> => One last thing, if your CPU's are baking out and crashing, are you not
> => nervous that under load this will happen no matter what the OS? Tweaking
> => system variables will not help you if your server is working ultra-hard,
> => at some point you will reach a mark that your system should still be able
> => to do which currently it can't.
> =>
> => I doubt hardware manufactuers put out equipment that can't run at 100% at
> => least.
>
> FWIW, I doubt the accuracy of that last paragraph, and don't think
> this is "so seemingly far fetched" at all. :-)
>
> I have a related problem. In my case, it's a borrowed laptop on which
> I installed FreeBSD 5.1-CURRENT (quite a while ago, but last
> {build,install}{kernel,world} was circa July 2003). Also installed on
> the system is Windows 2000 Professional. The related problem I have
> is that I can fairly easily get the laptop to power off due to
> thermally-initiated shutdown using FreeBSD (complete with "current
> temperature has exceeded system limits" type messages on the console
> beforehand), but can't seem to do so via Win2K. :-(
These are the same two (2) operating systems I am using. FreeBSD will cause my
AMD-MP's
to overheat while only idling --depending on the room temperature.
>
> Now I know that in a sense this is apples and oranges, because I don't
> do precisely the same things under both operating systems. But, it
> seems that high-CPU/system activity under FreeBSD will ultimately lead
> to a thermal shutdown, but not on Win2K (no so far as I've been able
> to manage, anyway).
Exactly what I'm experiencing unless and until I set the following:
machdep.apm_suspend_delay: 0
machdep.apm_standby_delay: 0
If i have the above two (2) lines set to:
machdep.apm_suspend_delay: 1
machdep.apm_standby_delay: 1
Its just a matter of time before one or more of the processors overheat and the box
shuts
down --without notice.
>This is inconvenient, to say the least. For
> example, a FreeBSD buildworld or buildkernel will not complete; it'll
> get part way through before the machine becomes too hot and shuts
> itself down. Similarly, building "big" ports like Mozilla won't
> complete, which makes portupgrade a bit of fun. Needless to say, this
> system doesn't get updated much. :-)
You may want to try and set those above variables to '0'
machdep.apm_suspend_delay: 0
machdep.apm_standby_delay: 0
>
> Now I'm not saying the machine doesn't become physically hot when
> running Win2K, too. It does (e.g., when playing CPU-intensive games,
> etc.). But somehow, Win2K is able to manage things so that the system
> does not become so hot that the shutdown kicks in.
>
Same here
> So, I'm wondering if there's some sysctl or other knob that can be set
> in FreeBSD that will ameliorate this problem.
Once again try:
machdep.apm_suspend_delay: 0
machdep.apm_standby_delay: 0
>(I thought
> laptop/mobile CPUs generally were able to step down to lower clock
> speeds to conserve power/run cooler, for example.) If I could do
> system rebuilds and port builds without having to restart that'd be a
> big improvement! :-)
>
> Unlike the original poster, this is an Intel-based system, not Athlon.
> It's a Gateway Solo 450 laptop.
This is strange, in comparison to my setup. The machine that's giving this overheat
problem is the build_box (AMD-MP). we have client machines that are all intel based;
P72,
P200 and a 1Ghz processor <-- these machines mount via NFS to the problem machine and
installworld and kernel using the same src, as the NFS mount implies, --none of the
client
machines needs the following variables/knobs set:
machdep.apm_suspend_delay: 0
machdep.apm_standby_delay:
Re: Overheating attributed to Freebsd --sysctl variables notavailable--
Jud, Annotated below - Original Message - From: "Jud" <[EMAIL PROTECTED]> To: "nw1" <[EMAIL PROTECTED]>; "peter lageotakes" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, November 04, 2003 6:06 AM Subject: Re: Overheating attributed to Freebsd --sysctl variables notavailable-- > On Mon, 3 Nov 2003 22:09:56 -0500, nw1 <[EMAIL PROTECTED]> wrote: > > > ----- Original Message - > > From: "Jud" <[EMAIL PROTECTED]> > > To: "nw1" <[EMAIL PROTECTED]>; "peter lageotakes" > > <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Monday, November 03, 2003 9:53 PM > > Subject: Re: Overheating attributed to Freebsd --sysctl variables > > notavailable-- > > > > > >> On Mon, 3 Nov 2003 19:57:38 -0500, nw1 <[EMAIL PROTECTED]> wrote: > >> > >> > > >> > > >> >> What version of FreeBSD are you using? > >> >> Did you compile amp into the kernel? > >> > > >> > I think you're not understanding what I posted @ > >> > http://69.3.136.141/freebsd/installation/sysctl_variables_missing > >> > > >> > The first line has what version I'm running. The entire document @ > >> > http://69.3.136.141/freebsd/installation/sysctl_variables_missing > >> > implies; this was a > >> > running system with no serious issues; meaning; the sysctl items I'm > >> > speaking of were in > >> > fact available and working. > >> > > >> > If i can figure out how to make these sysctl variables available, I > >> can > >> > set them like they > >> > were before, hence my overheating problem is solved. > >> > > >> > See what I mean? > >> > > >> >> > >> >> --- nw1 <[EMAIL PROTECTED]> wrote: > >> >> > The problem can be viewed @: > >> >> > > >> >> http://69.3.136.141/freebsd/installation/sysctl_variables_missing > >> >> > > >> >> > Basically, the machine is overheating (I believe) > >> >> > because the cpu's aren't cycling down. > >> >> > Previously I was able to cycle the processors down > >> >> > with the following sysctl variables: > >> >> > > >> >> > machdep.apm_suspend_delay: > >> >> > machdep.apm_standby_delay: > >> >> > > >> >> > however, for some reason those variables currently, > >> >> > aren't any where to be found by the > >> >> > up_and_running system. Please use the hyperlink > >> >> > above for details. > >> >> > > >> >> > Thanks for reading. All feedback is welcome. > >> > >> You may want to have a look at /usr/ports/sysutils/fvcool. (If you'd > >> like > >> a script to run it on startup, Dr. Matthew Seaman posted one to the > >> mailing list some months ago - January?) > > [Please don't top post - makes reading long threads more difficult.] > > > I'm interested in those missing sysctl variables I posted @ > > http://69.3.136.141/freebsd/installation/sysctl_variables_missing. > > Using a Third party > > application/script to fix something that was natively working or under > > control, I don't > > think, is the way to go and causes another level of complexity. > > > > Wouldn't you think? > > Ah - I thought you were interested in effectively and easily lowering your > AMD CPU temperatures by 10-20 degrees Celsius, rather than in getting help > searching for sysctl variables that had been more or less effective for > you in the past. > > BTW, if you wish to do "natively" what the fvcool "port" does, the > technical documentation at fvcool's site goes some way toward explaining > that. > > Sorry, my mistake. No problem, I am interested in any and all *sane/reasonable feedback. I haven't been to much a fan of using third party applications to fix something the original code or hardware should be able to handle. Thanks for your input. > > Jud > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overheating attributed to Freebsd --sysctl variablesnotavailable--
Annotated below. - Original Message - From: "Technical Director" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 03, 2003 11:07 PM Subject: Re: Overheating attributed to Freebsd --sysctl variablesnotavailable-- > > Forgive me for saying: > No need to ask for forgiveness. I'm looking for honest feedback. :) I have been working with both Tyan and AMD to resolve this, the issue is still here, --more below. > If this system is borked with FreeBSD due to the cpu's not cycling > 'down', then use a different operating system. FreeBSD is not responsible > for your trouble if you can solve the problem by moving on. Doing so and > solving the problem is more important than holding the OS and the > contributors to it accountable to something so seemingly far fetched. I'm kind of stuck on FreeBSD. Not interested in moving on to another *nix or any other OS for that matter. > > One way to test overall integrity of your hardware is to boot to bios and > leave it. Does it bake out on you? Then there is definitely something > wrong with your hardware, perhaps a fan is spinning less rpms than when > new. This has been done. Both the machine with the heat issue and his sister (18" apart) run neck and neck with respect to the hardware monitor readings, temperatures and such, and neither box, as you put it; "bakes out on me/us" <-- this has been tested overnight in a warm environment, the same environment that the OS runs in normally except for this test, we cut the air-conditioner off. This issue I'm dealing with only happens when Freebsd is loaded and the air conditioner is off. > > In my humble opinion this is probably not associated with the OS, but, > that doesn't solve 'your' problem. So besides seeing it for myself I can't > see an absolute need to use FreeBSD, in your words the problem, and not > use some other [$]NIX. > We would rather change hardware than leave FreeBSD --at this point. > One last thing, if your CPU's are baking out and crashing, are you not > nervous that under load this will happen no matter what the OS? Tweaking > system variables will not help you if your server is working ultra-hard, > at some point you will reach a mark that your system should still be able > to do which currently it can't. This does make absolute sense, but this isn't a publicly accessable machine, so it would rarely reach that max_load to cause it to overheat as its doing now, provided, I can find someone to answer the second outstanding question; Where are those sysctl variables that i was previously able to set? They are no longer available > > I doubt hardware manufactuers put out equipment that can't run at 100% at > least. > > My 2 cents. Your "2-cents" makes perfect sense, but as I posted above, I would rather replace either/ or both the motherboard and both processors. Before doing so, I had to hear what the community at large thinks about this. Thank you. :-) > > R. > > On Mon, 3 Nov 2003, nw1 wrote: > > > Both the board(s) and the processors were RMA'd. > > Both boards and all four (4) processors were swapped around between > both OS's and the > > problem remains using the hardware with the FreeBSD OS. The latest > BIOS is installed. > > > > We also have a newly purchased board (S-2466), the same thing occurs. > > > > Details @ http://69.3.136.141/freebsd/installation/sysctl_variables_missing > > > > - Original Message - > > From: "jon" <[EMAIL PROTECTED]> > > To: "nw1" <[EMAIL PROTECTED]> > > Sent: Monday, November 03, 2003 10:00 PM > > Subject: Re: Overheating attributed to Freebsd --sysctl variables notavailable-- > > > > > > > On Mon, 2003-11-03 at 19:57, nw1 wrote: > > > > > What version of FreeBSD are you using? > > > > > Did you compile amp into the kernel? > > > > > > > > I think you're not understanding what I posted @ > > > > http://69.3.136.141/freebsd/installation/sysctl_variables_missing > > > > > > > > The first line has what version I'm running. The entire document @ > > > > http://69.3.136.141/freebsd/installation/sysctl_variables_missing implies; this was a > > > > running system with no serious issues; meaning; the sysctl items I'm speaking > > > > of were > > in > > > > fact available and working. > > > > > > i can say from prior experience w/ hardware, if you system has > > > overheated you dont know where you stand (you may have damaged all kinds > > > of stuff, we had a b
Re: Overheating attributed to Freebsd --sysctl variables notavailable--
Both the board(s) and the processors were RMA'd. Both boards and all four (4) processors were swapped around between both OS's and the problem remains using the hardware with the FreeBSD OS. The latest BIOS is installed. We also have a newly purchased board (S-2466), the same thing occurs. Details @ http://69.3.136.141/freebsd/installation/sysctl_variables_missing - Original Message - From: "jon" <[EMAIL PROTECTED]> To: "nw1" <[EMAIL PROTECTED]> Sent: Monday, November 03, 2003 10:00 PM Subject: Re: Overheating attributed to Freebsd --sysctl variables notavailable-- > On Mon, 2003-11-03 at 19:57, nw1 wrote: > > > What version of FreeBSD are you using? > > > Did you compile amp into the kernel? > > > > I think you're not understanding what I posted @ > > http://69.3.136.141/freebsd/installation/sysctl_variables_missing > > > > The first line has what version I'm running. The entire document @ > > http://69.3.136.141/freebsd/installation/sysctl_variables_missing implies; this > > was a > > running system with no serious issues; meaning; the sysctl items I'm speaking of > > were in > > fact available and working. > > i can say from prior experience w/ hardware, if you system has > overheated you dont know where you stand (you may have damaged all kinds > of stuff, we had a board that over heated; then 2nd ide channel went > down, when we used micron ram!?! and micron was fine in board until the > overheat then any other brand ram worked) tyan has a three year warranty > use it! BUT my bet is there is a change in the chipset and you wont get > the sysctl mibs anyway. you try the newest BIOS flash? > > good luck > > if you want to ensure you get a new board, flex it until you stretch a > trace or two. > > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overheating attributed to Freebsd --sysctl variables notavailable--
I'm interested in those missing sysctl variables I posted @ http://69.3.136.141/freebsd/installation/sysctl_variables_missing. Using a Third party application/script to fix something that was natively working or under control, I don't think, is the way to go and causes another level of complexity. Wouldn't you think? - Original Message - From: "Jud" <[EMAIL PROTECTED]> To: "nw1" <[EMAIL PROTECTED]>; "peter lageotakes" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, November 03, 2003 9:53 PM Subject: Re: Overheating attributed to Freebsd --sysctl variables notavailable-- > On Mon, 3 Nov 2003 19:57:38 -0500, nw1 <[EMAIL PROTECTED]> wrote: > > > > > > >> What version of FreeBSD are you using? > >> Did you compile amp into the kernel? > > > > I think you're not understanding what I posted @ > > http://69.3.136.141/freebsd/installation/sysctl_variables_missing > > > > The first line has what version I'm running. The entire document @ > > http://69.3.136.141/freebsd/installation/sysctl_variables_missing > > implies; this was a > > running system with no serious issues; meaning; the sysctl items I'm > > speaking of were in > > fact available and working. > > > > If i can figure out how to make these sysctl variables available, I can > > set them like they > > were before, hence my overheating problem is solved. > > > > See what I mean? > > > >> > >> --- nw1 <[EMAIL PROTECTED]> wrote: > >> > The problem can be viewed @: > >> > > >> http://69.3.136.141/freebsd/installation/sysctl_variables_missing > >> > > >> > Basically, the machine is overheating (I believe) > >> > because the cpu's aren't cycling down. > >> > Previously I was able to cycle the processors down > >> > with the following sysctl variables: > >> > > >> > machdep.apm_suspend_delay: > >> > machdep.apm_standby_delay: > >> > > >> > however, for some reason those variables currently, > >> > aren't any where to be found by the > >> > up_and_running system. Please use the hyperlink > >> > above for details. > >> > > >> > Thanks for reading. All feedback is welcome. > > You may want to have a look at /usr/ports/sysutils/fvcool. (If you'd like > a script to run it on startup, Dr. Matthew Seaman posted one to the > mailing list some months ago - January?) > > Jud > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overheating attributed to Freebsd --sysctl variables notavailable--
I almost agree with you, except for one (1) or two (2) other factor(s): There is another case with the same motherboard, processors, and Ram running another OS which never ever shuts down due to heat as the one I described at http://69.3.136.141/freebsd/installation/sysctl_variables_missing. This other machine has many more IDE devices in it that is capable of generating more heat than the FreeBSD machine that's currently over heating, and the other machine never overheats or exhibits any instability. Hence, if you have two (2) machines with the same basic hardware and after swapping the hardware from one case to the other case --one by one, the only difference left is the OS and/ or the OS's settings. The last factor are those variables I mentioned (OS settings). When I set those variables in the past, the overheating subsided. As far as your opinion about the box crashing or overheating --its the cpu overheating because of instructions its receiving from the OS; proven by and in comparison to his sister running the same basic hardware, sitting 18" away from him. All of my Intel machines running the same version of FreeBSD, which by the way was installed from this build-box (Box-1) via NFS, doesn't have any heating or missing variable issues. I'm in no way suggesting this is solely a FreeBSD issue, but I have controlled this situation in the past with the variables that are currently unavailable for some unknown reason -- (http://69.3.136.141/freebsd/installation/sysctl_variables_missing) I'm all ears on this. I still haven't gotten feedback on the missing variables that very well should be available, but aren't. :-) Mr. Ulrich, I understand your position, however, do you understand mine? :-) - Original Message - From: "C. Ulrich" <[EMAIL PROTECTED]> To: "nw1" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, November 03, 2003 10:10 PM Subject: Re: Overheating attributed to Freebsd --sysctl variables notavailable-- > On Mon, 2003-11-03 at 17:38, nw1 wrote: > > The problem can be viewed @: > > http://69.3.136.141/freebsd/installation/sysctl_variables_missing > > > > Basically, the machine is overheating (I believe) because the cpu's aren't cycling down. > > Previously I was able to cycle the processors down with the following sysctl variables: > > > > machdep.apm_suspend_delay: > > machdep.apm_standby_delay: > > > > however, for some reason those variables currently, aren't any where to be found by the > > up_and_running system. Please use the hyperlink above for details. > > > > Thanks for reading. All feedback is welcome. > > Okay, this piqued my curiosity enough that I took a look at the message > in the URL above. > > Conclusion: FreeBSD doesn't even enter into it. The ONLY good solution > to this is to get better physical cooling of the CPUs (or the entire box > if you have to). Otherwise, you're still going to run into problems > whenever there's a full system load. Chances are, they're still running > way too hot even if they're not crashing the system. This will only > result in premature failure of the processors. Take it from the close > friend of an overclocker. :) If the machine is crashing (you only say > "overheating", which could mean either crashing or just getting > dangerously hot), then I would even go so far as to say that there's a > possibility that the stability of the processors is already decreasing, > leading to the more recent crashes. > > Charles Ulrich > -- > http://bityard.net > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overheating attributed to Freebsd --sysctl variables not available--
> What version of FreeBSD are you using? > Did you compile amp into the kernel? I think you're not understanding what I posted @ http://69.3.136.141/freebsd/installation/sysctl_variables_missing The first line has what version I'm running. The entire document @ http://69.3.136.141/freebsd/installation/sysctl_variables_missing implies; this was a running system with no serious issues; meaning; the sysctl items I'm speaking of were in fact available and working. If i can figure out how to make these sysctl variables available, I can set them like they were before, hence my overheating problem is solved. See what I mean? > > --- nw1 <[EMAIL PROTECTED]> wrote: > > The problem can be viewed @: > > > http://69.3.136.141/freebsd/installation/sysctl_variables_missing > > > > Basically, the machine is overheating (I believe) > > because the cpu's aren't cycling down. > > Previously I was able to cycle the processors down > > with the following sysctl variables: > > > > machdep.apm_suspend_delay: > > machdep.apm_standby_delay: > > > > however, for some reason those variables currently, > > aren't any where to be found by the > > up_and_running system. Please use the hyperlink > > above for details. > > > > Thanks for reading. All feedback is welcome. > > - > > All incoming attachments get deleted. > > Have a nice day. > > - > > > > ___ > > [EMAIL PROTECTED] mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > > > __ > Do you Yahoo!? > Exclusive Video Premiere - Britney Spears > http://launch.yahoo.com/promos/britneyspears/ > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Overheating attributed to Freebsd --sysctl variables not available--
The problem can be viewed @: http://69.3.136.141/freebsd/installation/sysctl_variables_missing Basically, the machine is overheating (I believe) because the cpu's aren't cycling down. Previously I was able to cycle the processors down with the following sysctl variables: machdep.apm_suspend_delay: machdep.apm_standby_delay: however, for some reason those variables currently, aren't any where to be found by the up_and_running system. Please use the hyperlink above for details. Thanks for reading. All feedback is welcome. - All incoming attachments get deleted. Have a nice day. - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sysctl variables not showing. -- FreeBSD-4.8-P13
FreeBSD 4.8-RELEASE-p13 The machine overheats. sysctl variables unable to be seen. Box-1 = NFS-server (the problem machine) Box-2 and above are NFS-clients The short version of the problem: After some overheating issues using: Two (2) AMD 1800+ MP processors In a Tyan Tiger MP (S-2460), it was discovered that setting the following knobs curbed the overheating: machdep.apm_standby_delay=0 machdep.apm_suspend_delay=0 Things went pretty smooth --for a while. Currently, we have the same two (2) AMD 1800+ MP's in a different board ="Tyan Tiger-MPX (S-2466)" -- now the box continues to overheat just as it did in the past (prior to setting the above sysctl knobs). When switching from the S-2460 to the S-2466, all we did was plug in the hdd's and go for it --things seem to work. Because the S-2466 is the successor to the S-2460, we didn't see any need for a fresh install --granted the chipset is a tad different.Could this different chipset be causing my problem(s)? Looking further into the problem, on Box-1: # sysctl machdep.apm_standby_delay sysctl: unknown oid 'machdep.apm_standby_delay # sysctl machdep.apm_suspend_delay sysctl: unknown oid 'machdep.apm_suspend_delay' As you can see, these knobs are no where to be found. The extreme strangeness is, The roll of this machine is one of a build-box; three (3) other machines on the LAN mount the necessary file systems via NFS to installworld and install their respective kernels from this machine, and yet, on those client machines I get the following: # sysctl -a | grep -i apm SWAPMETA:160, 3479,489,227, 1592 debug.apm_debug: 0 machdep.apm_suspend_delay: 1 machdep.apm_standby_delay: 1 - Using that same command on the --build machine-- aka: Box-1: # sysctl -a | grep -i apm SWAPMETA:160,31727, 0, 0,0 <-- is all we get. My questions are, at the very least: Why aren't those knobs -or- variables displayed using sysctl -a? Even though the aforementioned variables aren't seen using the above command, will setting those *unseen variables in /etc/sysctl.conf in fact get set? Thanks for your time reading this. - All incoming attachments get deleted. Have a nice day. - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Drive Geometry -- confusion.
Jim, Thanks for that, but I'm no closer to understanding my initial questions as seen on or at; https://69.3.136.141/freebsd/installation/geometry Why does the installation forbid us to use the 'physical geometry? --I'm sure there's a valid reason, I'd like to hear it. in this instance, can someone explain what to do and, why? for future reference. - Original Message - From: "Jim" <[EMAIL PROTECTED]> To: "nw1" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, October 29, 2003 8:46 AM Subject: RE: Drive Geometry -- confusion. > > > -Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of nw1 > > Sent: Wednesday, October 29, 2003 5:51 AM > > To: [EMAIL PROTECTED] > > Subject: Drive Geometry -- confusion. > > > > > > FreeBSD 4.8-RELEASE-p13 > > This document can also be viewed @ > > https://69.3.136.141/freebsd/installation/geometry > > > > Install 4.8 from CD-rom > > > > Drive Geometry confusion. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Drive Geometry -- confusion.
FreeBSD 4.8-RELEASE-p13 This document can also be viewed @ https://69.3.136.141/freebsd/installation/geometry Install 4.8 from CD-rom Drive Geometry confusion. My BIOS allows me a very limited amount of settings when it comes to an HDD. The following are the only settings offered by my BIOS: Read Prefetch - [Disabled | Enabled] - set to (Disabled) Disk Bios Translation - [LBA | CHS | Disabled] - set to (LBA) Local Bus IDE Mode - [High Performance | Compatible] - set to (High Performance) Size - 8455 MB --Auto-detected-- This is actually an 80GB HDD model: WD800JB. (Unable to change the 'Size' setting.) The only other setting that could remotely be associated with any HDD's installed would be the 'boot order' of the devices. ... sysinstall main menu | Custom | Partition : Here's where I'm confused; The following dialog message is printed: WARNING: A geometry of 155061/16/63 for ad0 is incorrect. Using a more likely geometry. If this geometry is incorrect or you are unsure as to whether or not it's correct, Please consult the Hardware Guide in the Documentation submenu or use the (G)eometry command to change it now. Remember: you need to enter whatever your BIOS thinks the geometry is! For IDE, it's what you were told in the BIOS setup. For SCSI, its the translation mode your controller is using. Do NOT use a "physical Geometry". ## With the above two (2) paragraphs having been said, All I have at this point is the physical geometry given by the WD800JB specs --which the above paragraphs are currently fobbing me to use. Lets press for OK and move further into this... We're in the FDISK Partition Editor where it states on the second line from the top: DISK Geometry: 9729 cyls/255 heads/63 sectors = 156296385 sectors (76316MB) If I understand correctly, the physical geometry of this WD800JB is: Cylinders = 16383 Heads = 16 Sectors/Track = 63 As seen on/at: The Westerndigital.com site. http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=699&p_cr eated=1037217622 I'm inclined to use the above three (3) values, however, The above FreeBSD installation 'dialog' expressly *forbids the use of the physical geometry. Is this not confusing to you as well? Why does the installation forbid us to use the 'physical geometry? --I'm sure there's a valid reason, I'd like to hear it. Can someone explain what to do and, for future reference, <-- *why do that? As stated above; I'm confused. - All incoming attachments get deleted. Have a nice day. - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD-4.8 -- Strange behavior using dump(8) --
This problem can be viewed @ http://69.3.136.141/freebsd/dump8/dump8_issue-1 - All incoming attachments get deleted. Have a nice day. - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.8-RELEASE-p13 -and- ntpd
After reading further, we've retired ntpdate from this network. Our issue may have been the order in which we ran ntpdate and xntpd within /etc/rc.conf ; subsequently (post reboot) immediately trying to run 'ntpdate xxx.xxx.x.x' would fail (as we posted on http://69.3.136.141/freebsd/ntpd/ntpd_issue-1.txt). We're not going to break it again in order to find out what went wrong. We are now 'ntpdate' *free*. We invite any and everyone else to do the same -- voluntarily retire 'ntpdate'. Thanks for your feedback. - Original Message - From: "Lowell Gilbert" <[EMAIL PROTECTED]> To: "nw1" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, October 09, 2003 8:52 AM Subject: Re: 4.8-RELEASE-p13 -and- ntpd > "nw1" <[EMAIL PROTECTED]> writes: > > > Our ntpd host syncs with the external public servers, but our local clients, using ntpdate > > to sync with the ntpd host (on the same sub-net), fails. Using ntpdate from the > > same > > local clients to any external public time-server works without problems. > > > > The details are posted at: http://69.3.136.141/freebsd/ntpd/ntpd_issue-1.txt > > I don't see anyting wrong there. > > The next step is to see whether the packets are hitting the wire, and > whether responses get back. You'll need to sniff the link. > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Update to earlier post (corrections)
We recently received our RMA'd board(s) back. These boards belong to the same family of the original board we did this install on/with. In plain English: initial install = Tyan Tiger-MP (S-2460) <-- USB mouse working upgraded = Tyan Tiger-MPX (S-2466) <-- USB mouse still working switched to: gigabyte GA-6bxds <-- mouse stopped working. The USB mouse was seen, but wasn't able to get mouse to respond with movement. dmesg | grep -I usb uhci0: port 0xa000-0xa01f irq 10 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 ums0: Logitech USB Mouse, rev 1.10/6.10, addr 2, iclass 3/1 as posted on: http://69.3.136.141/freebsd/usb_mouse.txt We tried both: device uhci# UHCI PCI->USB interface deviceohci# OHCI PCI->USB interface in the kernel config file. The USB mouse once again works now that the (S-2466) boards are back online. Would this be a case of: a) Murphys' Law b) Murphy & gigabyte/chipset/controller c) Gigabyte/chipset/controller d) Bad Karma Thanks for your previous input. - Original Message - From: "Kent Stewart" <[EMAIL PROTECTED]> To: "nw1" <[EMAIL PROTECTED]> Sent: Sunday, September 28, 2003 3:55 PM Subject: Re: Update to earlier post (corrections) > On Sunday 28 September 2003 10:17 am, you wrote: > > Please revist http://69.3.136.141/freebsd/usb_mouse.txt I've made > > things a little more clearer > > I have the same settings in my XF86Config. The last time I visited the > usb_startup, it did the moused. At this point, everything on your > system is consistant with what I have setup on my 4-stable and > 5-current systems. That means I don't have any idea what is different > about your system. > > FWIW, I have done exactly what you are doing and had no problems. I even > went from an Intel P-III 866 to an AMD 2000+ XP without having to > change anything. If it works on one and not the other, I would assume > that something is strange with the 2nd mobo. That isn't a firm rule > because Murphy likes to embarass us :). > > Coming from the diagnostic side of computing, I had a rule that 1 > positive wasn't a proof and that 1 failure was more important than any > number of sucesses. > > Kent > > > > > annotated below (your question) > > > > The mouse isn't working in the console or X > > > > - Original Message - > > From: "Kent Stewart" <[EMAIL PROTECTED]> > > To: "nw1" <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Sunday, September 28, 2003 12:55 PM > > Subject: Re: Update to earlier post (corrections) > > > > > On Sunday 28 September 2003 08:52 am, nw1 wrote: > > > > It will work with both moused and usbd specified in /etc/rc.conf. > > > > > > > > There is one thing i forgot to mention on that page: This > > > > install was created using another motherboard. The hdd's were > > > > transfered to this gigabyte motherboard. We have also tried > > > > doing a fresh install with the gigabyte board and enabling the > > > > same entries as posted on > > > > http://69.3.136.141/freebsd/usb_mouse.txt. In doing so the mouse > > > > works, which proves both usbd and moused can be enabled. > > > > > > > > My issue is it doesn't work at all now and I really can't do a > > > > fresh install. Recently i tried rm /dev/ums0 and recreating it, > > > > that still hasn't worked. > > > > > > What do you have setup in XF86Config for the protocol and mouse. > > > > Section "InputDevice" > > Identifier "Mouse0" > > Driver "mouse" > > Option "Protocol" "auto" > > Option "Device" "/dev/sysmouse" > > Option "Buttons" "5" > > Option "ZAxisMapping" "4 5" > > > > > Kent > > > > > > > - Original Message - > > > > From: "Kent Stewart" <[EMAIL PROTECTED]> > > > > To: "nw1" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > > > Sent: Sunday, September 28, 2003 11:33 AM > > > > Subject: Re: Update to earlier post (corrections) > > > > > > > > > On Sunday 28 September 2003 08:22 am, nw1 wrote: > > > > > > There were errors in an earlier post with a subject: FreeBSD > > > > > > 4.8-P10 --Mouse doesn't move in the console or XFree86-- > > > > >
4.8-RELEASE-p13 -and- ntpd
Our ntpd host syncs with the external public servers, but our local clients, using ntpdate to sync with the ntpd host (on the same sub-net), fails. Using ntpdate from the same local clients to any external public time-server works without problems. The details are posted at: http://69.3.136.141/freebsd/ntpd/ntpd_issue-1.txt Cheese ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD-4.8-p10 <--> Random reboots after swapping motherboard, cpu, memory
There weren't any hardware or architecture specific optimizations with the initial install, hence I don't think compiling just the kernel for our most recent motherboard would solve anything. I will say this; since we first posted this, we found out things were a bit out of sync (userland/kernel) and have since build and installed world and kernel. That solved the reboot issue, but it seems something else is corrupt within this install. Currently the box is UP and sitting idle, we look in on it every now an then to see if it randomly reboot since the most recent build/installworld. Soon the Tyan boards (S-2466) will be returned to us. With that being said, we may wait for those original boards to return and pop the hdd's back in their original place and see if things work, or if the install is wrecked beyond recognition (continued problems). Then we may very well dump|restore our valuable,data onto a fresh install. Other than that, trying to make it work with this most recent gigabyte setup may not be worth it and cause more problems than our original one. All we wanted to do was keep the box UP while the Tyan boards RMA'd. If you can offer anything further it would be most appreciated Thanks. :-) - Original Message - From: "anubis" <[EMAIL PROTECTED]> To: "nw1" <[EMAIL PROTECTED]> Sent: Monday, September 29, 2003 6:23 AM Subject: Re: FreeBSD-4.8-p10 <--> Random reboots after swapping motherboard, cpu, memory On Sat, 27 Sep 2003 06:48 am, nw1 wrote: > September 26, 2003 > > I initially installed 4.4 or 4.5 (Dec., 2001) subsequently cvsup'ing since > then (currently at 4.8-p10); using the following hardware: > > Main board - Tyan Tiger-MP (S-2460) | chipset: AMD-760 MPX > SMP using - AMD-MP 1800+'s > Ram - 768MB (crucial.com) > AGP - Matrox G450 eTV > Floppy drive = 1.44 > Western digital = model # WD102AA Caviar (UDMA/66 primary master) > Maxtor = model # 52049H4 (UDMA/100) -- Secondary master > Maxtor = model # 5T040H4 (UDMA/100) - Secondary slave > CD-rom = optional. > -- > Because of serious issues with the above S-2460 board, we retired them in > favor of the Tyan S-2466. Simply, we transferred the hardware from the > S-2460; to the S-2466 board. Everything seemed to run fine. > > Something unrelated happened with the S-2466 causing us to RMA the S-2466 > board(s). While those boards are being dealt with, we're left a few older > Intel platforms/hardware to work with: > > Giga-byte - GA-6BXDS > 1. Intel 82440 BX AGPset > 2. iTE 8671 I/Oset (1Mb/S) > 3. Winbond 83781 Health Chip > 4. Adaptec 7895 Dual Channel Ultra Wide SC > > We basically took our IDE devices and installed them on the gigabyte board. > Things seem to run OK, but that's not the case. The following three > things stand out: > > The machine randomly reboots while sitting idle -or semi-idle. With the > exception of the normal processes that start post boot. E.g. ntpd, > ntpdate, mbmon (from ports) nothing to intensive. ß From the console > standpoint, and that's our main concern. (console). > > In addition, from the console, our mouse has stopped working with the > following line in our /etc/rc.conf 'moused_enabled="YES"'. Our mouse is a > Logitech cordless optical Model number:M-RM67A (with fresh batteries). > > The above works fine with the TYAN boards in place. > > --Console Summary- > The machine randomly reboots. > The mouse doesn't respond/move in the console. > > -- Within XFree86 - > > X seems to run fine, but the mouse refuses to respond/work. > > I'm thinking this has something to do with the different boards or > chipsets, however, we have no idea where to begin in order to fix this. > > Respectfully yours, > > TR > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" Have you tried recompiling a kernel for the new board? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 4.8-P10 --Mouse doesn't move in the console or XFree86--
Alex: please see the update/corrections to this post at http://69.3.136.141/freebsd/usb_mouse.txt - Original Message - From: "Alex de Kruijff" <[EMAIL PROTECTED]> To: "nw1" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, September 28, 2003 1:44 PM Subject: Re: FreeBSD 4.8-P10 --Mouse doesn't move in the console or XFree86-- > On Sun, Sep 28, 2003 at 07:41:04AM -0400, nw1 wrote: > > Neither mouse will work in the console or in XFree86. > > > > Gigabyte GA-6BXDS = main board > > BIOS= AWARD (2A69KG01) ver. 4.51PG > > > > In the PCI/ISA section of the BIOS, a USB setting of: "Assign IRQ For USB: Enabled" (is > > set) > > There is also a "USB Keyboard Support" setting within the BIOS's "INTERGRATED > > PEROPHERALS" section; I have tried this setting to both "Enabled and Disabled". > > > > There aren't any other USB settings in this BIOS. > > > > We are using these devices that are known working devices. > > Mouse-1 is: Logitech | model: M-BD58 | optical corded wheel > > Mouse-2 is: Logitech | model: M-RM67A | Optical cordless wheel > > > > Our Kernel: > > # USB support > > device uhci# UHCI PCI->USB interface > > device usb # USB Bus (required) > > device ums # Mouse > > pseudo-device ether # Ethernet support > > > > Our /etc/rc.conf: > > # grep -i mouse /etc/rc.conf > > moused_enable="YES" > > moused_port="/dev/ums0" > > # grep -i usb /etc/rc.conf > > usbd_enable="YES" > > > > Our /dev: > > ls -l /dev | grep -i ums > > crw-rw 1 root operator 111, 0 Sep 27 13:16 ums0 > > > > dmesg reports: > > # dmesg | grep -i usb > > uhci0: port 0xa000-0xa01f irq 10 at > > device 7.2 > > on pci0 > > usb0: on uhci0 > > usb0: USB revision 1.0 > > ums0: Logitech USB Mouse, rev 1.10/6.10, addr 2, iclass 3/1 > > > > Upon booting into the OS, using the above BIOS, and other settings --with either of the > > above devices; the mouse is seen on screen, but it refuse to respond while moving > > the > > hand-held device. Should we unplug one mouse (from either usb port) to test the > > other > > mouse, we receive the following on-screen message(s), respectively of the > > motherboards USB > > port we were using: > > > > uhub0: device problem, disabling port 2 > > uhub0: device problem, disabling port 1 > > > > When we plug the devices back in to either of the motherboards mouse ports, > > there's no > > indication at all, from the OS, that a USB device was attached. > > > > Reminder: these devices are in perfect working order. > > It seems to be in order. As i see it thare are two posibilties. 1) Your > mouse isn't supported or 2) There is a (new) bug in the system. > > Did it work on previous version of FreeBSD? > > -- > Alex > > Articles based on solutions that I use: > http://www.kruijff.org/alex/index.php?dir=docs/FreeBSD/ > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Update to earlier post (corrections)
It will work with both moused and usbd specified in /etc/rc.conf. There is one thing i forgot to mention on that page: This install was created using another motherboard. The hdd's were transfered to this gigabyte motherboard. We have also tried doing a fresh install with the gigabyte board and enabling the same entries as posted on http://69.3.136.141/freebsd/usb_mouse.txt. In doing so the mouse works, which proves both usbd and moused can be enabled. My issue is it doesn't work at all now and I really can't do a fresh install. Recently i tried rm /dev/ums0 and recreating it, that still hasn't worked. - Original Message - From: "Kent Stewart" <[EMAIL PROTECTED]> To: "nw1" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, September 28, 2003 11:33 AM Subject: Re: Update to earlier post (corrections) > On Sunday 28 September 2003 08:22 am, nw1 wrote: > > There were errors in an earlier post with a subject: FreeBSD 4.8-P10 > > --Mouse doesn't move in the console or XFree86-- > > > > The udated particulars are posted at: > > 69.3.136.141/freebsd/usb_mouse.txt > > BTW, if you had added http://69.. we could click and browse your text > file. > > > > > I was always under the impression that you enabled moused or usbd but > not both. > > Kent > > -- > Kent Stewart > Richland, WA > > http://users.owt.com/kstewart/index.html > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Update to earlier post (corrections)
There were errors in an earlier post with a subject: FreeBSD 4.8-P10 --Mouse doesn't move in the console or XFree86-- The udated particulars are posted at: 69.3.136.141/freebsd/usb_mouse.txt Cheese ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 4.8-P10 --Mouse doesn't move in the console or XFree86--
Neither mouse will work in the console or in XFree86. Gigabyte GA-6BXDS = main board BIOS= AWARD (2A69KG01) ver. 4.51PG In the PCI/ISA section of the BIOS, a USB setting of: "Assign IRQ For USB: Enabled" (is set) There is also a "USB Keyboard Support" setting within the BIOS's "INTERGRATED PEROPHERALS" section; I have tried this setting to both "Enabled and Disabled". There aren't any other USB settings in this BIOS. We are using these devices that are known working devices. Mouse-1 is: Logitech | model: M-BD58 | optical corded wheel Mouse-2 is: Logitech | model: M-RM67A | Optical cordless wheel Our Kernel: # USB support device uhci# UHCI PCI->USB interface device usb # USB Bus (required) device ums # Mouse pseudo-device ether # Ethernet support Our /etc/rc.conf: # grep -i mouse /etc/rc.conf moused_enable="YES" moused_port="/dev/ums0" # grep -i usb /etc/rc.conf usbd_enable="YES" Our /dev: ls -l /dev | grep -i ums crw-rw 1 root operator 111, 0 Sep 27 13:16 ums0 dmesg reports: # dmesg | grep -i usb uhci0: port 0xa000-0xa01f irq 10 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 ums0: Logitech USB Mouse, rev 1.10/6.10, addr 2, iclass 3/1 Upon booting into the OS, using the above BIOS, and other settings --with either of the above devices; the mouse is seen on screen, but it refuse to respond while moving the hand-held device. Should we unplug one mouse (from either usb port) to test the other mouse, we receive the following on-screen message(s), respectively of the motherboards USB port we were using: uhub0: device problem, disabling port 2 uhub0: device problem, disabling port 1 When we plug the devices back in to either of the motherboards mouse ports, there's no indication at all, from the OS, that a USB device was attached. Reminder: these devices are in perfect working order. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD-4.8-p10 <--> Random reboots after swapping motherboard, cpu, memory
September 26, 2003 I initially installed 4.4 or 4.5 (Dec., 2001) subsequently cvsup'ing since then (currently at 4.8-p10); using the following hardware: Main board - Tyan Tiger-MP (S-2460) | chipset: AMD-760 MPX SMP using - AMD-MP 1800+'s Ram - 768MB (crucial.com) AGP - Matrox G450 eTV Floppy drive = 1.44 Western digital = model # WD102AA Caviar (UDMA/66 primary master) Maxtor = model # 52049H4 (UDMA/100) -- Secondary master Maxtor = model # 5T040H4 (UDMA/100) - Secondary slave CD-rom = optional. -- Because of serious issues with the above S-2460 board, we retired them in favor of the Tyan S-2466. Simply, we transferred the hardware from the S-2460; to the S-2466 board. Everything seemed to run fine. Something unrelated happened with the S-2466 causing us to RMA the S-2466 board(s). While those boards are being dealt with, we're left a few older Intel platforms/hardware to work with: Giga-byte - GA-6BXDS 1. Intel 82440 BX AGPset 2. iTE 8671 I/Oset (1Mb/S) 3. Winbond 83781 Health Chip 4. Adaptec 7895 Dual Channel Ultra Wide SC We basically took our IDE devices and installed them on the gigabyte board. Things seem to run OK, but that's not the case. The following three things stand out: The machine randomly reboots while sitting idle -or semi-idle. With the exception of the normal processes that start post boot. E.g. ntpd, ntpdate, mbmon (from ports) nothing to intensive. ß From the console standpoint, and that's our main concern. (console). In addition, from the console, our mouse has stopped working with the following line in our /etc/rc.conf 'moused_enabled="YES"'. Our mouse is a Logitech cordless optical Model number:M-RM67A (with fresh batteries). The above works fine with the TYAN boards in place. --Console Summary- The machine randomly reboots. The mouse doesn't respond/move in the console. -- Within XFree86 - X seems to run fine, but the mouse refuses to respond/work. I'm thinking this has something to do with the different boards or chipsets, however, we have no idea where to begin in order to fix this. Respectfully yours, TR ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD-4.8-p10 <--> Random reboots after swapping motherboard, cpu, memory
September 26, 2003 I initially installed 4.4 or 4.5 (Dec., 2001) subsequently cvsup'ing since then (currently at 4.8-p10); using the following hardware: Main board - Tyan Tiger-MP (S-2460) | chipset: AMD-760 MPX SMP using - AMD-MP 1800+'s Ram - 768MB (crucial.com) AGP - Matrox G450 eTV Floppy drive = 1.44 Western digital = model # WD102AA Caviar (UDMA/66 primary master) Maxtor = model # 52049H4 (UDMA/100) -- Secondary master Maxtor = model # 5T040H4 (UDMA/100) - Secondary slave CD-rom = optional. -- Because of serious issues with the above S-2460 board, we retired them in favor of the Tyan S-2466. Simply, we transferred the hardware from the S-2460; to the S-2466 board. Everything seemed to run fine. Something unrelated happened with the S-2466 causing us to RMA the S-2466 board(s). While those boards are being dealt with, we're left a few older Intel platforms/hardware to work with: Giga-byte - GA-6BXDS 1. Intel 82440 BX AGPset 2. iTE 8671 I/Oset (1Mb/S) 3. Winbond 83781 Health Chip 4. Adaptec 7895 Dual Channel Ultra Wide SC We basically took our IDE devices and installed them on the gigabyte board. Things seem to run OK, but that's not the case. The following three things stand out: The machine randomly reboots while sitting idle -or semi-idle. With the exception of the normal processes that start post boot. E.g. ntpd, ntpdate, mbmon (from ports) nothing to intensive. ß From the console standpoint, and that's our main concern. (console). In addition, from the console, our mouse has stopped working with the following line in our /etc/rc.conf 'moused_enabled="YES"'. Our mouse is a Logitech cordless optical Model number:M-RM67A (with fresh batteries). The above works fine with the TYAN boards in place. --Console Summary- The machine randomly reboots. The mouse doesn't respond/move in the console. -- Within XFree86 - X seems to run fine, but the mouse refuses to respond/work. I'm thinking this has something to do with the different boards or chipsets, however, we have no idea where to begin in order to fix this. Respectfully yours, TR ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
