On 19/09/14 06:44, Don Y wrote:> While I am at it, I should probably build a bunch of kernels > (of varying capabilities) to avoid this sort of issue in the > future! >All I can say here is that I am /so/ glad I use Linux rather than one of the BSD's. (Though I happily agree that BSD has its place, and is the stronger choice for some uses. The world would be poorer without the BSD's.) There is no point in going into detail here, and I know I am not going to change your mind. I'm just going to give a list of a few key phrases - if you need something to do during your kernel builds, you can look them up. If you want to discuss any of the items, that's fine. But I am not looking for a fight - I am merely trying to give suggestions that I think could make things easier for you. If you want to stick to BSD here, for whatever reasons, that's fine. - Recovery boots - Booting from a USB stick with persistent storage - Serial port console - Linux kernel parameters (choosing video modes, disabling hardware, etc.) - Hardware enumeration utilities (lspci, lsusb, lshw) - NFS mounts - Booting over NFS/TFTP Building my own kernels, especially for a trial-and-error test to identify problems, is probably the last thing I would consider.
Intel Atom: pros/cons/hazzards?
Started by ●September 17, 2014
Reply by ●September 19, 20142014-09-19
Reply by ●September 19, 20142014-09-19
Op Thu, 18 Sep 2014 19:25:13 +0200 schreef Don Y <this@is.not.me.com>:> On 9/18/2014 7:20 AM, Boudewijn Dijkstra wrote: >> Op Thu, 18 Sep 2014 09:28:45 +0200 schreef Don Y <this@is.not.me.com>: >>> On 9/17/2014 2:44 PM, mroberds@att.net wrote: >>>> In sci.electronics.design Don Y <this@is.not.me.com> wrote: >>> >>> [...] I tried booting >>> a NetBSD system and the video quickly scrambled (hard to see >>> the dmesg output to determine which device was probed at the >>> time). I'll have to make some time to investigate... >> >> *BSD supports serial console for headless boxen. If graphics probing >> causes problems, then you can disable the relevant drivers without >> rebuilding the kernel. > > Yes, the problem is figuring out *what* is causing the box to "hang". > Note that it could be "something else" that just happens to tickle > some graphics I/O, etc.My point was that you should be able to see this when using a serial console. -- (Remove the obvious prefix to reply privately.) Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Reply by ●September 19, 20142014-09-19
Op Fri, 19 Sep 2014 01:22:55 +0200 schreef rickman <gnuarm@gmail.com>:> On 9/18/2014 6:53 PM, Don Y wrote: >> On 9/18/2014 3:12 PM, rickman wrote: >>> Is NetBSD that different from Linux? I figured it was just another >>> flavor. >> >> Yes. Linux is JUST a kernel. NetBSD, FreeBSD, OpenBSD, PicoBSD, >> yadayadaBSD, etc. are all OS environments. E.g., what you would >> call "distros" in the Linux camp. > > When I say Linux, I am referring to all of those collectively.Please don't. http://www.freebsdnews.net/wp-content/uploads/unix_family_history_tree_1600x1200.jpg It's like saying birds to refer to all dinosaurs. It doesn't make any sense from a phylogenic standpoint. -- (Remove the obvious prefix to reply privately.) Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Reply by ●September 19, 20142014-09-19
On 9/19/2014 12:08 AM, rickman wrote:>>>>>> E.g., dmesg appears in red for this kernel. When the screen goes >>>>>> wonky, I can see the red text that has been scrolling by (correctly) >>>>>> up to this point -- amid a scrambled bunch of "white" video >>>>>> (as if HLock was lost). The red text stops scrolling -- as if the >>>>>> next probed item never got added to the output. >>>>> >>>>> That says to me the problem might well not be the video, but that the >>>>> video is an unintended victim of the real problem. I believe this >>>>> text >>>>> stream can be redirected to a file, no? Maybe that is the way to >>>>> go. Do >>>>> a postmortem on the text file. >>>> >>>> Yes, but the text file has to be *stored* somewhere that isn't >>>> volatile! I.e., you need writable media in the machine! ;) >>> >>> If you don't have writable media, what are you booting from, a CD with >>> no HD? So put a HD on it... >> >> Correct. It takes a 2.5" SATA drive. All of the 2.5" SATA drives >> that I have a large and "have stuff on them". So, putting a disk >> drive in the box means cleaning off one of these -- just to see >> why the video is getting scrambled, etc. >> >> As it isn't a "pressing need" (i.e., it can surely wait a week >> or two), the cost of making a disk *available* for it far exceeds >> the value of doing so! :-/ >> >> I *think* I have some "converters" that could let me adapt one >> of my PATA drives. OTOH, they might be the exact "wrong" >> type of converters... >> >> (I could also drag out a 3" SATA drive, am external power supply >> and hack together some suitable cables... again, a lot of work >> vs. just waiting until I can get my hands on some smaller/disposable >> SATA drives) > > If you have some larger drives available, can't you just copy one of the > laptop drives to the larger one, then it is free for the Atom system... > That would be 5 minutes of your time and whatever time for it to copy.The 500G drives are 2.5's. So, to clear one off, I would need at least 500G of space on another (e.g., 3.5") drive.> Or can the Linux distro boot from a USB stick? Surely you have one of > those around... > > Aren't there a bunch of ways to skin this cat?Sure! All take varying amounts of time. And, EVENTUALLY, I will *still* have to build a kernel to run on this machine! So, why not just wait until I have a smaller (capacity) drive that can STAY in the machine, forever? Build the kernel appropriately and solve ALL the problems (instead of investing time just to figure out what NOT to put in the kernel -- that I will still have to build and configure even after I know what this machine's "issue" happens to be!)>>>> I.e., the only way I can move forward is to build a "system" >>>> and then let that system boot -- having a disk on which to >>>> scribble log messages. Of course, if the system doesn't >>>> get to multiuser state (or, if the network IF doesn't come up), >>>> then there is no way to troubleshoot *that*. >>> >>> So adding a HD is "building a system"? The software you are booting >>> doesn't know about hard drives? Really? >> >> No. Add a hard drive and install the system *on* that hard drive >> (so that the system knows it has a place to scribble -- which it >> doesn't know when booting off a read-only medium). >> >> If you're going to put the system on the disk, then you might >> as well spend the half hour to customize the kernel so it stands >> a better chance of getting past whatever is causing the live CD to >> scramble video... > > I thought the whole point was you didn't know what to configure the > system for!You build a stripped down kernel. One that doesn't have various video, network, wireless, SCSI HBA, etc. drivers present. I.e., so all it knows about is a "barebones PC architecture" (hence the reason for my initial question re: Atom's). If you can't boot *that*, then there's no hope! :> Once you *can*, you examine the dmesg output from the first boot. It will tell you which devices are present but not yet configured (i.e., missing drivers) in the "stripped down kernel". Add those lines back into the kernel's configuration file. Rebuild. Install as final OPERATING kernel. In practice, you start with a kernel configuration file that supports everything and comment out all but the most basic components -- to arrive at the "barebones PC". Call this netbsd.BAREBONES (kernels are named /netbsd by convention). Examine the dmesg from this boot. Find the drivers that are missing (by notes in the dmesg) and uncomment them in your "new" kernel configuration file. Then: config NEWKERNELNAME cd ../compile/NEWKERNELNAME make depends make make install and reboot. If you've been observant, you've now got a kernel (NEWKERNELNAME) that supports everything you want in the new hardware/machine. As the Atom's will run x86 code, the initial BAREBONES kernel can be built on any x86 NetBSD box and just copied onto the disk that will LIVE in the new machine -- along with the rest of the "system". Once it has booted, the new kernel can be built ON that new machine. A few weeks ago, I did exactly this for another "new" box: made a copy of an existing x86 system (complete filesystem) on a new disk drive. Installed drive. Noted which devices were not correctly probed (dmesg). Modified the kernel configuration file. Rebuild (as illustrated above). Then, reboot. [Unfortunately, the laptop drive that I did this on has already died. Unsure if it was from abuse or if it was just "getting on in years". So, I'll have to do it again -- perhaps using one of these boxes to replace that machine]>>>> So, best shot for getting The Answers on the first shot is to >>>> build a stripped down kernel -- remove any drivers that are >>>> not essential. *Hope* it gets through the boot sequence >>>> (to "single-user"). Then, examine the dmesg output to see >>>> which devices it detected but didn't "configure" (because the >>>> corresponding drivers weren't wired in). >>> >>> If you want to do all that work. Or you could plug a hard drive to it. >> >> See above. Just *adding* a hard disk to the system (AND CONTINUING >> TO BOOT OFF THE LIVE CD) will result in exactly the same situation >> that I have now -- messages won't get stored anywhere because the >> system has no knowledge of how "acceptable" it would be to >> scribble on that disk! >> >> Normally, the kernel buffers diagnostic/log messages while it is >> booting. When it is "up" (or, nearly so), these are flushed to >> log files -- typically under /var/log. If the entire file system >> is represented by a live CD, then /var/log is not writeable. >> No way to see what it *would* have scribbled there! > > If you are booting from a CD I guess there is no way to tell the system > that it needs to log to the HD anyway.Correct. If, OTOH, the system was booting from a hard disk, then /var/log would be writeable and the log files would populate that portion of the filesystem in the natural course of events. Similarly, if I can get to a command prompt, I can manually mount some other writeable medium (e.g., thumb drive).>>>> If you can get a console, building a "custom" NetBSD kernel >>>> tailored for that particular device is no more than half an hour, >>>> start to finish. >>> >>> Plugging in a hard drive is 5 minutes and the first 4 is finding a >>> cable. >> >> See above. All that would do is *eventually* list a hard disk >> as one of the devices probed in the system -- *if* the boot >> managed to make it that far. >> >> Take a virgin machine. Try to install Linux, Windows, BeOS, OSX, etc. >> You've got executables on a CD/DVD. And, a disk onto which you can >> scribble! >> >> But, if you can't get to a command prompt, you can't tell the >> machine to *use* that disk to scribble! > > Well duh! Is it that hard to make an installation on the HD without > recompiling it all? I can do that with Windows. You just use a > different machine.Yes, *knowing* (point of my post!) that Atom's can execute i386 binaries in a functionally equivalent manner means I can just build a BAREBONES kernel on another machine and copy the "complete filesystem" onto the new disk. Then, install in the new machine.>>>>>>>> Yes, that's what I've already been doing on the various boxes. >>>>>>>> Lets me build custom kernels for each box's capabilities, etc. >>>>>>>> >>>>>>>> Perhaps next step will be to try a *Windows* install if only to >>>>>>>> get an enumeration of the various "devices" in the box! Then, >>>>>>>> use that information to build an appropriate kernel. >>>>>>> >>>>>>> Linux can't do that? >>>>>> >>>>>> It, perhaps, can. I just don't run Linux. And, imagine it >>>>>> wasn't *designed* with Linux in mind but, rather, "Windows" >>>>>> (of some flavor). So, I'd expect putting Windows on it would >>>>>> "work" -- at least enough to allow me to inspect its hardware >>>>>> complement. >>>>>> >>>>>> I'll have to see if I have a smallish 2.5" SATA drive that I >>>>>> can "waste". All I've found so far are > 500GB. >>>>> >>>>> Is NetBSD that different from Linux? I figured it was just another >>>>> flavor. >>>> >>>> Yes. Linux is JUST a kernel. NetBSD, FreeBSD, OpenBSD, PicoBSD, >>>> yadayadaBSD, etc. are all OS environments. E.g., what you would >>>> call "distros" in the Linux camp. >>> >>> When I say Linux, I am referring to all of those collectively. When you >>> say you don't run Linux, you mean... whatever... this can be >>> exasperating sometimes. >> >> That's like saying "Windows" and meaning OSX, Linux, *BSD, Solaris, >> etc. > > Sometimes you make no sense. You just said Linux is the kernal for all > of those systems. Now you are saying it is the kernal for Windows > too... okNo! Linux is *a* kernel. In DOS parlance, it is COMMAND.COM... for Linux Distros -- and ONLY for Linux Distros! NetBSD's kernel (entirely different source code -- because there's no GPL code contained within!) is used in NetBSD. FreeBSD's kernel is used in FreeBSD. OpenBSD's kernel is used in OpenBSD. etc. The *BSD kernels share some code but are maintained by different groups and with different goals. So, a FreeBSD kernel won't support NetBSD executables and vice versa (actually, there are some compatibility options that can be used but the kernels aren't just "drop in replacements"). My above statement was meant to illustrate that calling all of these (NetBSD, OpenBSD, FreeBSD, OSX, PicoBSD, etc.) "Linux" is wrong. Just like it would be wrong to call Linux "Windows"! NetBSD is NetBSD. Linux is Linux. What they have in common is they are maintained in an "open" fashion -- unlike "Windows". Linux, e.g., had its roots in more of a SysV flavor while the BSD's were (not surprisingly) derived from the Berkeley Software Distribution (of "UNIX").> Is BSD not at all based on Linux?No. Different evolutions, goals, licenses, etc. That was the point I was trying to make.> Regardless, don't get hung up on the terminology.>> With a system on disk (or, CD if I want to endlessly burn CD's!), >> I can boot a specific kernel: >> boot netbsd.STRIPPED_DOWN >> and observe the results. Then, modify this kernel (add in some >> devices not present in STRIPPED_DOWN) and reboot, specifying this >> *new* kernel: >> boot netbsd.A_FEW_DEVICES >> and repeat until I find the change that causes the screen to go >> wonky. > > Or others have suggested you work over a serial port. Is there no > serial port on this machine? Can you use a USB serial port?If the kernel is crashing, then it doesn't matter if I use a serial port or the console. Once <whatever> device is probed during the boot, the system will "go away". A dead serial console is just as bad as a dead *console*! Instead of trying to avoid the problem, I'll just *solve* it; when I have a smaller disk that I am willing to *commit* to this machine! Solve problem and end up with *working* machine -- instead of just a description of the problem followed by actually having to MAKE that working machine! As I said, this is usually a pretty simple process. This is the first time that I've not been able to take "any old kernel" and get to a point where I can start modifying that kernel. Usually, the big issues are NICs (so, no network connectivity until you get the "right" kernel built) and more exotic I/O's (e.g., SCSI HBA's, wireless adapters, PCMCIA support, etc.). This is the first time that the video hardware has not liked being tickled the way the kernel wants to tickle it!
Reply by ●September 19, 20142014-09-19
On 9/19/2014 4:02 AM, Boudewijn Dijkstra wrote:> Op Fri, 19 Sep 2014 01:22:55 +0200 schreef rickman <gnuarm@gmail.com>: >> On 9/18/2014 6:53 PM, Don Y wrote: >>> On 9/18/2014 3:12 PM, rickman wrote: >>>> Is NetBSD that different from Linux? I figured it was just another >>>> flavor. >>> >>> Yes. Linux is JUST a kernel. NetBSD, FreeBSD, OpenBSD, PicoBSD, >>> yadayadaBSD, etc. are all OS environments. E.g., what you would >>> call "distros" in the Linux camp. >> >> When I say Linux, I am referring to all of those collectively. > > Please don't. > http://www.freebsdnews.net/wp-content/uploads/unix_family_history_tree_1600x1200.jpg > > > It's like saying birds to refer to all dinosaurs. It doesn't make any > sense from a phylogenic standpoint."Ontogeny recapitulates phylogeny" - Ernst Haeckel -- Rick
Reply by ●September 19, 20142014-09-19
On 9/19/2014 12:36 AM, Boudewijn Dijkstra wrote:> Op Thu, 18 Sep 2014 19:25:13 +0200 schreef Don Y <this@is.not.me.com>: >> On 9/18/2014 7:20 AM, Boudewijn Dijkstra wrote: >>> Op Thu, 18 Sep 2014 09:28:45 +0200 schreef Don Y <this@is.not.me.com>: >>>> On 9/17/2014 2:44 PM, mroberds@att.net wrote: >>>>> In sci.electronics.design Don Y <this@is.not.me.com> wrote: >>>> >>>> [...] I tried booting >>>> a NetBSD system and the video quickly scrambled (hard to see >>>> the dmesg output to determine which device was probed at the >>>> time). I'll have to make some time to investigate... >>> >>> *BSD supports serial console for headless boxen. If graphics probing >>> causes problems, then you can disable the relevant drivers without >>> rebuilding the kernel. >> >> Yes, the problem is figuring out *what* is causing the box to "hang". >> Note that it could be "something else" that just happens to tickle >> some graphics I/O, etc. > > My point was that you should be able to see this when using a serial > console.No, it seems that the machine is locking up when this happens. In the past, I've always just built a GENERIC kernel, partitioned the new disk, newfs(1) all partitions, filled fstab(5) and copied all the file system from a "template" system onto the new disk... all from within that "template system". Then, unplug the disk and install it in the new machine. EXPECT the network not to work and other devices to need to be tweeked. But, copy the GENERIC kernel configuration to NEWMACHINE, drop into vi(1) and edit NEWMACHINE to add/remove/change the appropriate lines. Build new kernel (now I am *on* the new machine!) and install it. This is the first time that I have *had* to rely on a live CD. Lesson learned: build a live cd that has a barebones kernel (which tries to be the least of all worlds) instead of GENERIC (which tries to be all things to all machines). I.e., instead of trying to have a running system on a live CD, try for a DEBUGGABLE system.
Reply by ●September 19, 20142014-09-19
On 9/19/2014 12:19 AM, David Brown wrote:> Building my own kernels, especially for a trial-and-error test to > identify problems, is probably the last thing I would consider.A kernel has to be built EVENTUALLY! Why invest time in some other pursuit and *hope* you can relate that to the actual kernel that you will ultimately build? I don't think you understand just how easy it is to build (or modify) a *BSD kernel. Edit a text file (if you are clever, you will start with a suitable kernel configuration file to reduce the total number of keystrokes) having the name of your new kernel configuration -- e.g. FOO. config FOO cd ../compile/FOO make depend make make install reboot (of course, the makes can all be condensed to a single line). On a 1GHz machine, it's about 30 minutes to a command prompt on the *new* kernel -- most of that time spent waiting for the compiler. If you are building the kernel on another "host" machine, then you omit the "install" and "reboot" stages and, instead, copy the resulting kernel to the new medium. Once *that* machine can boot, you can further tweek the kernel (by editing "FOO" -- which can be embedded in the actual kernel image with a configuration option if you want to make your life easy!)
Reply by ●September 19, 20142014-09-19
On 19/09/14 10:36, Don Y wrote:> On 9/19/2014 12:19 AM, David Brown wrote: > >> Building my own kernels, especially for a trial-and-error test to >> identify problems, is probably the last thing I would consider. > > A kernel has to be built EVENTUALLY! Why invest time in some > other pursuit and *hope* you can relate that to the actual > kernel that you will ultimately build?A kernel has to be built - but it certainly doesn't have to be built by the user. I don't know much about building kernels in the BSD world, but in the Linux world it is a very long time since it was common to bother building your own kernel. Unless you want to patch the kernel, use bleeding-edge versions before your distro has them in place, have /really/ weird hardware, or you are doing kernel development, then there is usually almost nothing to be gained by building it yourself. For most distros, most of the drivers and many of the other features of the kernel are built as modules. This means they take up some disk space, but are not loaded and don't use any resources unless they are actually used. The difference in ram between compiling something as a module and compiling it statically is seldom more than a few percent, and the difference in speed is less than that. So unless disk space is a premium, standard practice is to use a kernel with suitable base characteristics (such as a "server" or "workstation" kernel, featuring slightly different options aimed at high throughput or low latency), and with most other parts as modules. That way, your kernel boots quickly and has all the drivers you need. If you change your hardware (add a new network card, plug in a USB device, or whatever), the modules are there. If you connect something with an odd filesystem (say, a USB stick formatted for MacOS or BSD), the modules are there and load automatically as needed. The cost is a bit of disk space. (Distro builds usually don't include /all/ the drivers and modules - there are plenty of esoteric drivers and features that are not included.)> > I don't think you understand just how easy it is to build > (or modify) a *BSD kernel. Edit a text file (if you are > clever, you will start with a suitable kernel configuration > file to reduce the total number of keystrokes) having > the name of your new kernel configuration -- e.g. FOO. > config FOO > cd ../compile/FOO > make depend > make > make install > reboot > (of course, the makes can all be condensed to a single line). > > On a 1GHz machine, it's about 30 minutes to a command prompt > on the *new* kernel -- most of that time spent waiting for the > compiler.Building Linux kernels is not dissimilar. Usually you use the menu system ("make menuconfig") rather than editing the configuration file manually, but the process is roughly the same. Of course, the Linux kernel is far bigger than the BSD kernel, supporting an order of magnitude more devices, boards, and other features, but the idea is the same. I don't know off-hand how long it takes to build a typical PC kernel - in recent times I have only built for embedded systems (where I needed modified drivers). So yes, I understand perfectly well how simple it is to build a kernel (BSD or Linux) - and I am still perfectly happy not to bother doing so. Building a BSD kernel may be easy, but it is no easier than building a Linux kernel - and it is certainly no where near as easy as simply using a pre-build Linux kernel.> > If you are building the kernel on another "host" machine, then > you omit the "install" and "reboot" stages and, instead, copy > the resulting kernel to the new medium. > > Once *that* machine can boot, you can further tweek the kernel > (by editing "FOO" -- which can be embedded in the actual kernel > image with a configuration option if you want to make your life > easy!) >You make that sound like a unique feature. But like almost anything else in the kernel, anything that BSD has, Linux has too - and usually has had it for longer. The advantage of the BSD's over Linux (and Linux distros) are in having a smaller and simpler system, with fewer features, but with a more centralised development team. The aim is not to support everything, but to give good support for key features - thus they can focus on security and reliability for a smaller software base. None of the BSD's attempt to compete with Linux or the Linux distros on features, hardware support, software support, speed, or ease of use. The differences in license is, for almost everybody, irrelevant. The difference in the development model and focus is key.
Reply by ●September 19, 20142014-09-19
On 9/19/2014 2:53 AM, David Brown wrote:> The differences in license is, for almost everybody, irrelevant. The > difference in the development model and focus is key.Because, for almost everybody, you aren't designing products that you do NOT want encumbered with GPL. I surely don't care to invest my time updating sources -- that I will then NOT be able to distribute sans GPL! Especially when there are unencumbered alternatives! "For almost everybody", the only difference between a FOSS license and a Windows/OSX license is some dollars. How many folks do you know who lament NOT being able to patch the Windows/OSX/iOS/etc. sources? They just want to use apps supported ON that OS. [If the cost of a Windows/OSX/etc. license is an impediment, then I suspect they truly misunderstand the cost and value *of* the product they are using. Or, are just plain "cheap". Yet, probably would cringe at the idea of not being compensated for *their* work!]
Reply by ●September 19, 20142014-09-19
On 19/09/14 12:10, Don Y wrote:> On 9/19/2014 2:53 AM, David Brown wrote: > >> The differences in license is, for almost everybody, irrelevant. The >> difference in the development model and focus is key. > > Because, for almost everybody, you aren't designing products > that you do NOT want encumbered with GPL. I surely don't care > to invest my time updating sources -- that I will then NOT > be able to distribute sans GPL! > > Especially when there are unencumbered alternatives!Almost everybody who /is/ designing products will choose Linux over BSD. This is because almost everybody who is designing an embedded *nix system does not care about keeping the code for the kernel secret, nor the code for the base system or the libraries. They didn't write it - why should they keep it secret? At most, they will have made a couple of drivers for the kernel - and by making them open they can get others to help maintain them. Of course, people making embedded Linux systems will generally have plenty of their own code in the system - and that will often be under closed licenses with secret code. But that's perfectly fine - the GPL applies to the kernel, not programs running with it. And once you get beyond the kernel itself to the libraries and common utilities, most of these are exactly the same programs in BSD and Linux systems. Some (such as ssh) are basically from the BSD world, others (such as the gnu utilities) come originally as Unix alternatives, and others come from the Linux world. It's all open source, it's all freely available, and it is all usable on different systems despite license differences.> > "For almost everybody", the only difference between a FOSS license > and a Windows/OSX license is some dollars. How many folks do you > know who lament NOT being able to patch the Windows/OSX/iOS/etc. > sources? They just want to use apps supported ON that OS. > > [If the cost of a Windows/OSX/etc. license is an impediment, > then I suspect they truly misunderstand the cost and value > *of* the product they are using. Or, are just plain "cheap". > Yet, probably would cringe at the idea of not being compensated > for *their* work!]In many cases, the cost of /administering/ Windows licenses (especially embedded ones) outweighs the cost of the licenses themselves! People choose embedded Linux for their products because it is a better system for many uses than embedded Windows. You are right that the license cost is (or should be!) a minor issue. A telephone manufacturer must pay MS more for their patent protection racket when they use Android than they would pay to use Windows Phone - but they use Android because it is a better system.
