dc0: TX underrun -- resetting
Hi all, Just saw two identical console messages on a 3-day old 4.0-CURRENT machine: dc0: TX underrun -- resetting Nothing special was happening on the near or far end of the link, system is very lightly loaded. The only network activity was a telnet session from another host. No unusual daemons running (actually, just the stock daemons). This card is communicating directly with another identical card, 100BaseTX full duplex. I never saw these messages with the pn0 driver under -STABLE or earlier with the same card. (FA310TX (Lite-On chipset)). Is this just a new diagnostic message in 4.0? No connections were dropped that I could see. -- Ryan Thompson [EMAIL PROTECTED] Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-20000307-CURRENT kern.flp keyboard probe questions
Jeffrey J. Mountin wrote to Ryan Thompson: At 09:19 PM 3/10/00 -0600, Ryan Thompson wrote: Me as well...For at least a decade. I used to do it manually all the time, but had occasional glitches with funny scan codes and indicator statuses. With a mid-range priced switch, though, I have had no problems whatsoever. The only glitches I ever see are with a mouse. Tap me on the shoulder while my hand is on the mouse and it will seize. For my use at home there isn't a need for a switch. Could use one at times, but it's simple enough to swap around at need. The old 2-button 9-pin $5 serial Dexxa mice were really fun.. I used to buy the OEMs in bulk. They were a comfy little mouse, but, shine direct sunlight on them and the optical disc motion sensors wouldn't work. The cheap, thin plastic casing allowed light to shine through and confuse the eye. -- Ryan Thompson [EMAIL PROTECTED] Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
4.0-20000307-CURRENT kern.flp keyboard probe questions
Hi all... Maybe there is a valid reason for this, but when I attempt to boot the 4.0 kern.flp without a keyboard attached (I share one keyboard between four systems, here), it displays keyboard: no and the BTX loader message, and ceases to display ANY output on the attached monitor (though it does continue to access the disk, I'm assuming, until the MFS root floppy is needed)? I assume this is because, without a keyboard, the loader assumes a serial console is attached. This is not the case in my situation. Isn't there a better way to identify a serial console? And, if not, could the loader at least not display a message on the local monitor like "Switching output to serial console...", or better yet, "Switching output to serial console in 10 seconds.. press any key to abort"? IMO, something like the above might avoid some confusion in the future. -- Ryan Thompson [EMAIL PROTECTED] Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-20000307-CURRENT kern.flp keyboard probe questions
Kazutaka YOKOTA wrote to Ryan Thompson: Maybe there is a valid reason for this, but when I attempt to boot the 4.0 kern.flp without a keyboard attached (I share one keyboard between four systems, here), it displays keyboard: no and the BTX loader message, and ceases to display ANY output on the attached monitor (though it does continue to access the disk, I'm assuming, until the MFS root floppy is needed)? I assume this is because, without a keyboard, the loader assumes a serial console is attached. Yes. And this has been the behavior since FreeBSD 2.X. I thought as much. This is not the case in my situation. Isn't there a better way to identify a serial console? I don't understand. What do you expect the boot loader to do? I'm not sure, that's why I asked the list :-) Really, what I was asking is if there is a better way to detect a serial console.. Rather than the current logic of "If there is no keyboard, there must be a serial console". I can think of N reasons why a box would have no keyboard attached, besides having a serial console. I know very little about serial consoles, but can they not be probed somehow to determine their existence? If that's not possible, at least, what I'm suggesting below still sounds reasonable. And, if not, could the loader at least not display a message on the local monitor like "Switching output to serial console...", or better yet, "Switching output to serial console in 10 seconds.. press any key to abort"? Which key do you mean? The system has found no keyboard, you know :-) Kazu Exactly... My suggestion resembles the common BIOS boot message from days of old: Keyboard not found. Press [F1] to continue. The novice reads, laughs out loud, and wonders if the joke is really on them. After all, how COULD they press F1 if a keyboard does not exist? The expert checks his/her keyboard connection, (or plugs a keyboard in) and, indeed, hits F1 to continue. BIOS programmers have been doing it for about two decades. Why not the FreeBSD boot loader? :-) My idea is a similar one. Have the boot loader (with a reasonably configured timeout--we don't want to wait indefinitely) display a similar message (perhaps with copious beeping), giving the busy sysadmin a chance to switch keyboards, or at least notice that a keyboard was not detected. If I install FreeBSD on multiple systems, I might throw boot disks in a dozen machines so I don't have to wait for each one. I come around with my $370 keyboard later to start the actual installs over NFS. I call it 'pipelining' :-) -- Ryan Thompson [EMAIL PROTECTED] Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Keyboard troubles
Why does it seem like I'm posting a lot of messages about keyboards, today? :-) I seem to remember hearing a similar problem a month or two ago, and do not remember if it was resolved. I couldn't remember enough about it to find it in the list archives. In any case, I at least want to say "me too". On my -current system, after rebooting, the keyboard was in a funny state (all 4 LEDs were turned on. My keyboard also has an internal click mechanism, which was no longer functional) I plugged the keyboard into another machine at that point, and it reset itself and worked fine on that machine. Plugging it back into the -current box, however, produced the same results as before. Fearing incompatibility, I dug out an old AT keyboard and plugged it in. No LEDs lit, and also no response from keypresses (including the obvious escape characters). The machine didn't hang... console message were still being displayed. I ended up rebooting the thing remotely, and after that, the keyboard functioned normally. If somebody can tell me what else to check, I can try and provide a few mroe details. -- Ryan Thompson [EMAIL PROTECTED] Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-20000307-CURRENT kern.flp keyboard probe questions
Mike Smith wrote to Ryan Thompson: Isn't there a better way to identify a serial console? I don't understand. What do you expect the boot loader to do? I'm not sure, that's why I asked the list :-) Really, what I was asking is if there is a better way to detect a serial console.. Rather than the current logic of "If there is no keyboard, there must be a serial console". I can think of N reasons why a box would have no keyboard attached, besides having a serial console. Actually, there aren't very many. If you don't have a keyboard, you need a console of some sort. If you don't have a console, you've made enough modifications to be undaunted by removing two bytes from /boot.config. "Don't have a keyboard" != "No keyboard detected" != "Serial Console". I understand the reasoning and rationale behind the logic used, and I agree with it, to a point. Read below. I have indeed disabled the keyboard probe in /boot.config when doing many installs to avoid the problem that I mentioned... But I always yearned for something a little less awkward, when I can otherwise still use install disks from the distribution images. I know very little about serial consoles, but can they not be probed somehow to determine their existence? If that's not possible, at least, what I'm suggesting below still sounds reasonable. No, they can't be probed, and no, if you think about it for a minute, what you're proposing is entirely nonsensical. Ok, so they can't be probed. However, I HAVE thought about it for a minute, and, to be honest, I still don't see why my proposal is entirely nonsensical. :-) Would you mind explaning your argument? For clarity, I'll explain mine again... Perhapas we're just not on the same wavelength: From boot(8): -P probe the keyboard. If no keyboard is found, the -D and -h options are automatically set. Instead of that behaviour, I am suggesting a more forgiving behaviour: 1. Probe for a keyboard. 2. Is there a keyboard? Yes - Boot from the local console No - Display "Keyboard not found. Using serial console in 10 seconds, press any key to abort" 3. Was a key pressed in 10 seconds? Yes - Boot from the local console No - Display "Booting from serial console" Boot from the serial console Nothing is lost, besides an extra 10 seconds at bootup, and a smidgen of the code segment. If no keyboard is detected, and there is indeed a serial console, it will still be used automatically. If, however, there was a temporary probing problem (i.e., the keyboard was not yet plugged in), the installer can smack a key and continue on. I'm open to the idea that I'm being nonsensical (I'll usually be the first one to admit it), but, in this case, I just don't see your reasoning, Mike. Please clarify. -- Ryan Thompson [EMAIL PROTECTED] Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keyboard troubles
Kazutaka YOKOTA wrote to Ryan Thompson: It sounds like the keyboard interface of your motherboard has somewhat become flaky; it may even be broken. It is NOT recommended that you attach or detach the keyboard while the power is on. The keyboard interface of the PC motherboard is not designed for hot-plugging/unplugging. It is too easy to fry the keyboard interface and/or controller by doing so. I don't make a habit of keyboard swapping, and I HAVE experienced some minor glitches before (such as weird scan codes being sent, or the state of caps lock changing). In any case, though, a keyboard reset or even just a few key presses would fix. In the last 10 years, I have NEVER had to reboot a system because they keyboard wasn't responding. Even if the keyboard interface survives hot-plugging, there is no assurance that the keyboard and the keyboard controller on the motherboard can communicate properly after hot-plugging; they are simply not designed to cope with such situation. I personally know a couple of people who broke their motherboard this way. Bummer for them.. Really, though, I would rather fry a $200 motherboard than my $500CDN keyboard (my fingers have developed expensive tastes). :-) None of my motherboard documentation warns agains swapping keyboards, either. In any case, I never had problems swapping keyboards between prior FreeBSD releases, other UNIX platforms, Windows machines, DOS machines. Hell, even my old Nintendo never complained if you plugged in a different controller while it was powered on. :-) I was just wondering if something had been done to 4.0 that didn't handle this situation like previous releases. Thanks for the info. When I have another $500 burning a hole in my checkbook, I will probably order another keyboard, just so I have another one, if nothing else. :-) - Ryan -- Ryan Thompson [EMAIL PROTECTED] Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-20000307-CURRENT kern.flp keyboard probe questions
Mike Smith wrote to Ryan Thompson: "Don't have a keyboard" != "No keyboard detected" != "Serial Console". No keyboard detected - local console won't be used - use serial console Yes, that would seem to sum up the current behavior quite well. :-) Ok, so they can't be probed. However, I HAVE thought about it for a minute, and, to be honest, I still don't see why my proposal is entirely nonsensical. :-) Would you mind explaning your argument? For clarity, I'll explain mine again... Perhapas we're just not on the same wavelength: From boot(8): -P probe the keyboard. If no keyboard is found, the -D and -h options are automatically set. Instead of that behaviour, I am suggesting a more forgiving behaviour: 1. Probe for a keyboard. 2. Is there a keyboard? Yes - Boot from the local console No - Display "Keyboard not found. Using serial console in 10 seconds, press any key to abort" This is as stupid as the "Keyboard error - Press F1 to continue" message that several BIOS vendors are so fond of. If there's no keyboard attached, you can't hit a key. Not very smart. :-) I just mentioned that in another (now closely related) thread. 3. Was a key pressed in 10 seconds? Yes - Boot from the local console No - Display "Booting from serial console" Boot from the serial console There's also not enough code space in the bootstrap for this frippery. If you want to use a local keyboard, make sure it's plugged in. We don't have a diagnostic for when you forget eg. to install your disk drive either... That's a concern that I stated in my previous post. If it's not feasable, then it's not feasable. (And I can infer from your responses that you wouldn't be the one to commit such frippery to the codebase, anyway :-) It was but an idle query from someone mildly inconvenienced by -P. Thanks for the input. - Ryan -- Ryan Thompson [EMAIL PROTECTED] Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keyboard troubles
Brian Dean wrote to Ryan Thompson: Ryan Thompson wrote: Thanks for the info. When I have another $500 burning a hole in my checkbook, I will probably order another keyboard, just so I have another one, if nothing else. :-) Why not just get a decent monitor/keyboard switch? Belkin makes a nice 4-port in the $200 range that makes your motherboard think there's a keyboard attached even if you are not currently switched onto the system. I have something quite similar.. Still, seems like some individuals remain adamantly opposed to the idea of keyboard swapping, however careful one is. :-) Just a thought ... and it's a lot cheaper than more convenient that swapping your $500 keyboards (which must be _really_ impressive BTW :). They are... A small electronics firm in Saskatchewan was nice enough to help me design and manufacture something to fit my needs. (They even let me play with their expensive CAD tools to design the hardware key repeat :-). Actually, they gave me a really good price, considering their costs. I programmed it with a custom key layout (actually, something very close to Dvorak), but some key positions are different, and I've even got a few extra keys that I've wired macros to. I used to nicely exceed 100WPM on a $20 QWERTY keyboard. My QWERTY speed, understandably, has dropped to ~80, while my customized Dvorak speed jumped to about 110 sustained. -- Ryan Thompson [EMAIL PROTECTED] Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-20000307-CURRENT kern.flp keyboard probe questions
Jeffrey J. Mountin wrote to Mike Smith: At 05:54 PM 3/10/00 -0800, Mike Smith wrote: Since you can't safely hot-plug the PC keyboard, that wouldn't be very smart. The only way to auto-detect the use of a serial console is to look for a keyboard; if one isn't plugged in, there's no local console, end of story. Can't safely? Why the hell not? Been hot-swapping keyboards for many years without *any* problems. Old DIN style and PS2, doesn't matter. Even Doze doesn't mind. Me as well...For at least a decade. I used to do it manually all the time, but had occasional glitches with funny scan codes and indicator statuses. With a mid-range priced switch, though, I have had no problems whatsoever. If/when this does change, wishing there will be a way to override back to the current behaviour. IMO, serial console should be explicitly called for. Amen. If I can't boot a system to the local console without a keyboard, that system isn't very useful. If the default DOES change, you should be able to change your boot.config to remove the -P option. -- Ryan Thompson [EMAIL PROTECTED] Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: is it really at the end of its lifecycle?
On Wed, 15 Dec 1999, Daniel C. Sobral wrote: Peter Jeremy wrote: [...] Motif, it's several times the size of the Xserver. Unless we want to mandate the use of ZIP drives (or similar) as FreeBSD install floppies, we're limited to a syscons (or VTxxx) sysinstall. There is a device called cd-rom which more or less qualifies for the "or similar" category you mention. It happens to be the most popular installation media nowadays (though it probably comes second as far as FreeBSD is concerned). If memory serves, I first joined FreeBSD in 2.2.3, and I've at one point or another ran just about every release in between, (and many more source builds in between THOSE) up to 3.4-RC, which I'm running today on some development/test machines. I have made dozens of installs of FreeBSD, and have logged a great deal of time in sysinstall on running systems. I have often wondered if FreeBSD would benefit from a graphical installer. As an experienced administrator of FreeBSD on a variety of systems, new and old, I am satisfied with the current text-based offering. As someone who was once an inexperienced administrator of FreeBSD, I was satisfied with the then-text-based offering. (Which, for those of you that don't remember, was remarkably similar to the current text-based offering :-) Daniel, here, sees the X install as being "user-friendly". Is the text based install not? Granted, it's not the point and click interface that windows users are accustomed to, but, clearly, if users can't navigate the menus and manage to find their way to a help menu (and don't know how to read install documentation)... It could be reasonably argued that they are going to experience a rude awakening when presented with the good old root prompt. From a techical standpoint, yes, an X based install would be far too large for a single floppy, even at the simplest level. AND, again, as someone who has installed FreeBSD dozens of times on various systems, I think I should also stress that I have NEVER installed FreeBSD from CD :-) For the average newbie "wanna try it" user, buying the CDs, books and everything neat in a box, is more often than not the safest and simplest route to take. In that case, putting a graphical installer on the CD would be a viable option. To take this a step further, why not keep (or keep something similar to) the current sysinstall, but have an option to fetch, install, configure and run X and another GUI installer distribution, then start the X server and continue the installation process from there? The first portion of the install (selecting media type, allocating space, and labeling) could remain text-based, whereas the user could then be presented with a "Get X and continue installation graphically?" option, which would then download/copy/read a (possibly minimal) X binary distribution, small window manager--TWM would probably suffice :-), as well as the graphical installer. No additional floppy storage space required. The rest of the install, including distribution download, package install, startup config, and all the other wonderful goodies, plus (possibly) a graphical disk partition/labeling utility for post-install changes, would all be done within the comfort of X, after a relatively small download/copy/read is done from their chosen media. Or... To take this ANOTHER small step further... For systems with enough memory (this certainly wouldn't justify increasing the requirements), the text installer could mount a large MFS partition to hold minimal X, window manager and installer... Fetch automatically, do a VERY simple configure from selected media, and continue with the install, INCLUDING a graphical disk partitioner/labeller, after that. Of course, with any of these options, development time and relative cost would be an issue, but, all things being equal, it may result in a flexible install option that a) still runs on virtually any supported platform, and b) gives systems with graphical support the option of a very good looking installer :-) Given the primary mission of sysinstall is to load FreeBSD, I'd go so far as to say that developing an X version would be wasting valuable developer resources (IMHO, of course). X install = "user-friendly" install (perceived as) = more market share = more resources -- Daniel C. Sobral (8-DCS) who is as social as a wampas [EMAIL PROTECTED] [EMAIL PROTECTED] --- Ryan Thompson [EMAIL PROTECTED] 50% Owner, Technical and Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
