Intel Atom: pros/cons/hazzards?

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:
>>
>>>>> If you wanted to run the graphics at full capability, though, you
>>>>> sometimes needed a driver from Intel or the SBC manufacturer, and you
>>>>> would run into the usual problem, which is that their unspecified
>>>>> "Linux driver" depended on a particular kernel version down to the
>>>>> ninth decimal place.
>>>>
>>>> Exactly.  So much for "open" software!  :>
>>>
>>> If I remember right, the proprietary graphics driver was closed-source.
>>> It's entirely possible, and (I am not a lawyer and this is not legal
>>> advice) probably within the terms of the GNU GPL, and other open-source
>>> licenses, to have proprietary software running "on top of" an open-
>>> source OS.  It just tends to be a pain in the butt in practice.
>>
>> I don't *think* these have integrated video.  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.

Until I can *see* the dmesg output, it's just a guessing game.
Easier to build a stripped down kernel with *nothing*, see what's
going on, make note of the "not configured" devices, then add
then back in.

(sigh) Everything just takes *time*  :-/

In sci.electronics.design Don Y <this@is.not.me.com> wrote:
> I don't *think* these have integrated video.

According to Wikipedia (would they lie to you?), the Atoms released in
2008 didn't have integrated video, but the later ones did.  I think I
was working with the "Pineview" [ND][45].. series chips, which did.

> 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...

I haven't played with BSD much lately, but newer Linux distributions
seem to compile the kernel to ask for something other than 80x25 text
fairly early in the boot process - I think this is mostly so you can see
more of the boot-time messages on the screen.  If BSD is doing the same
thing, perhaps that change is causing trouble.  Linux has a "vga="
kernel boot parameter that lets you force a video mode.

Linux also has a "console=" boot parameter that can give you a serial
console if you want, and I think this happens early enough that it gets
the kernel boot messages.  Hook up your Teletype and party like it's
1969!  :)

The last time I played with BSD a lot, it was FreeBSD, and I got the
impression that while the security and networking was better than Linux,
the device support was not nearly as good as Linux.

> Perhaps next step will be to try a *Windows* install if only to get
> an enumeration of the various "devices" in the box!

My checkout step was usually to boot a Linux live CD/DVD, using an
external optical drive with its own power supply.  In theory, you can
put a bootable image on a USB stick, but I have found that the boot
image, USB stick, BIOS, and phase of the moon must all align to get
this to work right - the external optical drive was slower but much
more likely to work.

Matt Roberds

On 9/18/2014 12:33 PM, mroberds@att.net wrote:
> In sci.electronics.design Don Y <this@is.not.me.com> wrote:
>> I don't *think* these have integrated video.
>
> According to Wikipedia (would they lie to you?), the Atoms released in
> 2008 didn't have integrated video, but the later ones did.  I think I
> was working with the "Pineview" [ND][45].. series chips, which did.

 From what I can gather looking at the "Setup" screen, this is
an earlier series -- Diamondville -- Atom 330 (dual core, 1.6GHz,
IA-64, Hyperthreading capable.  *No* GPU (seems consistent from the
number of heatsinks in the box)

>> 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...
>
> I haven't played with BSD much lately, but newer Linux distributions
> seem to compile the kernel to ask for something other than 80x25 text
> fairly early in the boot process - I think this is mostly so you can see
> more of the boot-time messages on the screen.  If BSD is doing the same
> thing, perhaps that change is causing trouble.  Linux has a "vga="
> kernel boot parameter that lets you force a video mode.

No idea what the kernel on the Live CD that I was using was built as.
Hence, the reason it's easier to just build a new one from scratch
*knowing* what sort of cruft you've thrown into the pot.

> Linux also has a "console=" boot parameter that can give you a serial
> console if you want, and I think this happens early enough that it gets
> the kernel boot messages.  Hook up your Teletype and party like it's
> 1969!  :)

<frown>  Have to eBay the TTY soon.  One more thing to get rid of.
(last time I checked, folks were spending $1K on the silly things!)

> The last time I played with BSD a lot, it was FreeBSD, and I got the
> impression that while the security and networking was better than Linux,
> the device support was not nearly as good as Linux.

I started out with NetBSD back at v0.8.  (maybe 1993?)  Soon moved to
FreeBSD (at the time, they were at 0.9, IIRC) because they were
*solely* focused on i386 (NetBSD was pursuing many architectures
concurrently -- admirable but meant getting an i386 box with the
features that I wanted WORKING was more effort).  Stayed there until
about 2.2.7/8 (maybe 1998?).  Then, disappointed with the falling
quality (esp the ports/packages collection) -- and, having acquired
a bit of larger iron (unsupported on FreeBSD) -- moved back to NetBSD.

Which is where I have stayed, since (at least in terms of my own
workstations/servers that run FOSS).

>> Perhaps next step will be to try a *Windows* install if only to get
>> an enumeration of the various "devices" in the box!
>
> My checkout step was usually to boot a Linux live CD/DVD, using an
> external optical drive with its own power supply.  In theory, you can
> put a bootable image on a USB stick, but I have found that the boot
> image, USB stick, BIOS, and phase of the moon must all align to get
> this to work right - the external optical drive was slower but much
> more likely to work.

Yeah, I opted to boot from an external CD-ROM with a "live CD"
than to bother installing a real system (actually, I didn't have
a small enough disk drive to waste on the task :< ).

I'll make a list of which boxes I can discard/replace in the event
that these little things prove "suitable".  Then, evaluate the
effort to investigate more fully.  (also gives me some time to
round up smaller disk drives)

On 9/18/2014 6:31 AM, Don Y wrote:
> On 9/18/2014 12:41 AM, rickman wrote:
>> On 9/18/2014 3:28 AM, Don Y wrote:
>>> I don't *think* these have integrated video.  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...
>>
>> Can't you boot it with the console being another machine over the
>> network?
>
> Even assuming the NIC is recognized and autoconfigured, it doesn't
> *appear* that the system is surviving this "scrambled video"
> event.
>
> 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.


>>> Database isn't obscene.  It doesn't see many queries but those
>>> that it does field tend to be a bit complex (lots of joins, etc.)
>>
>> Just remember that these CPUs would have been top dog some 10 years ago.
>>   So anything that would have been easy for that period hardwware should
>> be easy for them now.  Well, maybe not.  I had a VIA CPU which was
>> clocked around 1.something GHz and it was a dog.  I replaced it with a
>> Celeron later and got better performance.  It had a passive heat sink,
>> but the PSU still had a fan.
>
> Some of the boxes I would like to replace are far more capable
> (e.g., one is a 2U double dual-core machine with ~12G of RAM...
> but, it's much bigger and more capable than I need -- it just
> happened to be something "unused" when I pressed it into service)

Wow, it is only my most recent laptop that has that much ram.  I design 
FPGAs and got by on 3 GB for some time.


>>> 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.

I don't think the computers are designed for any OS.  The OS is modified 
for the newest processors and chips.  Motherboards are just designed for 
target markets.

-- 

Rick

On 9/18/2014 3:12 PM, rickman wrote:
>>>> I don't *think* these have integrated video.  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...
>>>
>>> Can't you boot it with the console being another machine over the
>>> network?
>>
>> Even assuming the NIC is recognized and autoconfigured, it doesn't
>> *appear* that the system is surviving this "scrambled video"
>> event.
>>
>> 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!  ;)

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, 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 can get a console, building a "custom" NetBSD kernel
tailored for that particular device is no more than half an hour,
start to finish.

>>>> Database isn't obscene.  It doesn't see many queries but those
>>>> that it does field tend to be a bit complex (lots of joins, etc.)
>>>
>>> Just remember that these CPUs would have been top dog some 10 years ago.
>>>   So anything that would have been easy for that period hardwware should
>>> be easy for them now.  Well, maybe not.  I had a VIA CPU which was
>>> clocked around 1.something GHz and it was a dog.  I replaced it with a
>>> Celeron later and got better performance.  It had a passive heat sink,
>>> but the PSU still had a fan.
>>
>> Some of the boxes I would like to replace are far more capable
>> (e.g., one is a 2U double dual-core machine with ~12G of RAM...
>> but, it's much bigger and more capable than I need -- it just
>> happened to be something "unused" when I pressed it into service)
>
> Wow, it is only my most recent laptop that has that much ram.  I design
> FPGAs and got by on 3 GB for some time.

I've lived with far less.  My first boxes (386) had 12MB -- and the
memory alone set me back $1500/box!

I don't think any of the workstations on which I spend most of my
time have more than 3G usable.  Not sure of the laptops as I spend very
little time with them.

The blade server has 14? dual dual-core's in it each with 4G, IIRC.
But, it dims the lights when I fire it up... :<

>>>> 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.

The *BSD's also have a different heritage -- all outgrowths of
the 386BSD sources (1991/2) -- derived from (ultimately) the 4.3BSD
(Net/2) distribution.

The key difference between the *BSD's and the Linux camp is the
licensing terms that are applied.  I.e., you can FREELY take the
NetBSD kernel, modify it, include it in commercial products, etc.
without ever having to share -- or make available the sources from
which you started -- any of your modifications/enhancements with
others[1]  (IIRC, you have to acknowledge the copyright on the
inherited code and that's about it)

I.e., you aren't "encumbered" with the GPL's terms.  You are free
to "make the codebase yours" -- as if you had developed it entirely
"in house" (subject to the copyright notice restriction and the
indemnification of the original copyright holders, etc.)

The same is true of FreeBSD/PicoBSD, OpenBSD, etc.

[And, there is far less of a "fanboy" attitude surrounding it/them
and its/their development]

> I don't think the computers are designed for any OS.  The OS is modified
> for the newest processors and chips.  Motherboards are just designed for
> target markets.

Yes, but if a market embraces Windows, then the product effectively
was "designed for Windows".

[1] The same can not be said of the NetBSD "OS" -- as it includes
many applications that are covered under less permissive licensing
terms (e.g., much FSF code).

On 9/18/2014 6:53 PM, Don Y wrote:
> On 9/18/2014 3:12 PM, rickman wrote:
>>>>> I don't *think* these have integrated video.  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...
>>>>
>>>> Can't you boot it with the console being another machine over the
>>>> network?
>>>
>>> Even assuming the NIC is recognized and autoconfigured, it doesn't
>>> *appear* that the system is surviving this "scrambled video"
>>> event.
>>>
>>> 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...


> 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?


> 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.


> 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.


>>>>> Database isn't obscene.  It doesn't see many queries but those
>>>>> that it does field tend to be a bit complex (lots of joins, etc.)
>>>>
>>>> Just remember that these CPUs would have been top dog some 10 years
>>>> ago.
>>>>   So anything that would have been easy for that period hardwware
>>>> should
>>>> be easy for them now.  Well, maybe not.  I had a VIA CPU which was
>>>> clocked around 1.something GHz and it was a dog.  I replaced it with a
>>>> Celeron later and got better performance.  It had a passive heat sink,
>>>> but the PSU still had a fan.
>>>
>>> Some of the boxes I would like to replace are far more capable
>>> (e.g., one is a 2U double dual-core machine with ~12G of RAM...
>>> but, it's much bigger and more capable than I need -- it just
>>> happened to be something "unused" when I pressed it into service)
>>
>> Wow, it is only my most recent laptop that has that much ram.  I design
>> FPGAs and got by on 3 GB for some time.
>
> I've lived with far less.  My first boxes (386) had 12MB -- and the
> memory alone set me back $1500/box!
>
> I don't think any of the workstations on which I spend most of my
> time have more than 3G usable.  Not sure of the laptops as I spend very
> little time with them.
>
> The blade server has 14? dual dual-core's in it each with 4G, IIRC.
> But, it dims the lights when I fire it up... :<
>
>>>>> 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.

The point is that why can't your version of Linux "distro" do the 
enumeration?


> The *BSD's also have a different heritage -- all outgrowths of
> the 386BSD sources (1991/2) -- derived from (ultimately) the 4.3BSD
> (Net/2) distribution.
>
> The key difference between the *BSD's and the Linux camp is the
> licensing terms that are applied.  I.e., you can FREELY take the
> NetBSD kernel, modify it, include it in commercial products, etc.
> without ever having to share -- or make available the sources from
> which you started -- any of your modifications/enhancements with
> others[1]  (IIRC, you have to acknowledge the copyright on the
> inherited code and that's about it)
>
> I.e., you aren't "encumbered" with the GPL's terms.  You are free
> to "make the codebase yours" -- as if you had developed it entirely
> "in house" (subject to the copyright notice restriction and the
> indemnification of the original copyright holders, etc.)
>
> The same is true of FreeBSD/PicoBSD, OpenBSD, etc.
>
> [And, there is far less of a "fanboy" attitude surrounding it/them
> and its/their development]
>
>> I don't think the computers are designed for any OS.  The OS is modified
>> for the newest processors and chips.  Motherboards are just designed for
>> target markets.
>
> Yes, but if a market embraces Windows, then the product effectively
> was "designed for Windows".

Ok, whatever....  by your definition of "designed for Windows" it has no 
useful meaning.

-- 

Rick

On 9/18/2014 4:22 PM, rickman wrote:
> On 9/18/2014 6:53 PM, Don Y wrote:
>> On 9/18/2014 3:12 PM, rickman wrote:
>>>>>> I don't *think* these have integrated video.  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...
>>>>>
>>>>> Can't you boot it with the console being another machine over the
>>>>> network?
>>>>
>>>> Even assuming the NIC is recognized and autoconfigured, it doesn't
>>>> *appear* that the system is surviving this "scrambled video"
>>>> event.
>>>>
>>>> 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)

>> 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...

>> 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!

[Of course, if the kernel never makes it all the way "up", then
all bets are off, anyway!]

If the kernel manages to boot, you can still examine these "in core"
messages AS IF they were entered in the log file (dmesg(8) dumps
the "system message buffer").  So, in *most* situations, I can
boot a live CD, wait for the prompt, type "dmesg | more" and examine
the various messages to see what devices are present, how much
memory, etc.

If I can get to a command prompt, I can manually mount a thumb
drive and copy the messages to that medium (dmesg > /mnt/messages.txt)

Or, I can manually bring up a network interface and move stuff
on/off via that mechanism.

[But, I need access to a command prompt to do so!]

>> 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!

>>>>>> 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.

*BSD is different from Linux as Linux is different from Windows and
Windows is different from OSX...

"I don't run Linux"  I also don't run OSX.  So, if OSX could "do it",
I'd be just as SOL.

> The point is that why can't your version of Linux "distro" do the
> enumeration?

My NetBSD "live cd" never gets to a command prompt for me to be
able to *see* what it is saying!  I can watch the first part
of the boot process... see the first group of devices successfully
probed (have to look fast because it scrolls by in a jiffy)...
But, it gets to a point where the screen gets scrambled.

Looking at the screen, I can see much of the previous messages
(in red-colored text) still present.  But, it is as if the
HSync has been lost so nothing is clear/readable.

What I want/need to know is the message that it was getting ready to
emit just as the screen went wonky.   If the kernel is truly crashed,
then I wouldn't be able to get this message from it even if I had
a means of typing:
     dmesg | more
If just the video is crashed, it is possible that the kernel is
still functioning (doubtful) but I can't talk to it -- because
I can't type at the "console" and the network isn't "up".

The solution is to install a simpler kernel (e.g., I can live
without USB support, network interface, wireless, etc. WHILE
I am troubleshooting) and then watch to see what the LIKELY
problem may be.

The fact that the kernel is able to emit messages for a portion
of the boot process suggests the video can operate as a "dumb
text console" (because it *is* -- up until that point!).  I
just need to make sure nothing interferes with it *continuing*
to do so.

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.

>>> I don't think the computers are designed for any OS.  The OS is modified
>>> for the newest processors and chips.  Motherboards are just designed for
>>> target markets.
>>
>> Yes, but if a market embraces Windows, then the product effectively
>> was "designed for Windows".
>
> Ok, whatever....  by your definition of "designed for Windows" it has no
> useful meaning.

It means I am more likely to find a Windows release that will
run "flawlessly" on this particular set of hardware.  Even if
the device/driver that is (probably) causing my problem is
completely proprietary/closed.

OTOH, expecting Linux, *BSD, OSX to run on "any random hardware"
is a bit of a crap shoot.

On Thu, 18 Sep 2014 17:18:03 -0700, Don Y <this@is.not.me.com> wrote:

>
>My NetBSD "live cd" never gets to a command prompt for me to be
>able to *see* what it is saying!  I can watch the first part
>of the boot process... see the first group of devices successfully
>probed (have to look fast because it scrolls by in a jiffy)...
>But, it gets to a point where the screen gets scrambled.
>
>Looking at the screen, I can see much of the previous messages
>(in red-colored text) still present.  But, it is as if the
>HSync has been lost so nothing is clear/readable.

Say Don how hard would it be to try a different monitor?  A different
native resolution may not scramble.

?-)
 

Hi Joseph,

On 9/18/2014 9:16 PM, josephkk wrote:
> On Thu, 18 Sep 2014 17:18:03 -0700, Don Y <this@is.not.me.com> wrote:
>
>> My NetBSD "live cd" never gets to a command prompt for me to be
>> able to *see* what it is saying!  I can watch the first part
>> of the boot process... see the first group of devices successfully
>> probed (have to look fast because it scrolls by in a jiffy)...
>> But, it gets to a point where the screen gets scrambled.
>>
>> Looking at the screen, I can see much of the previous messages
>> (in red-colored text) still present.  But, it is as if the
>> HSync has been lost so nothing is clear/readable.
>
> Say Don how hard would it be to try a different monitor?  A different
> native resolution may not scramble.

That;s an option.  But, note that the "scrolling text" that would
normally appear (and has appeared up until this point) appears to
have stopped scrolling.   I.e., if you could filter out the sync
problems, you would see that the underlying image is static from
the moment the scrambling starts -- not as if the scrolling had
continued and has finally stopped at a "login" prompt.

It's as if something has been wonked and/or the system is expecting
a result that it isn't getting (from the hardware).

In an effort to get at dmesg(8) output without building a new
kernel, I tried a few other "products" that I had lying around
on CD (to save me the hassle of having to fire up file server,
download images and burn).

An old FreeBSD install CD (1998) complained loudly!  "bounce memory".
A recent OPHCrack CD resulted in the same scrambling (I believe
it is Linux based).

However, a Clonezilla CD didn't fret (when configured 800x600 as
its default offering).  Accessing a shell from there, I was able
to mount a thumb drive and copy the dmesg output to it!  (because
"dmesg | more" apparently doesn't work the same way under Linux
as it does under *BSD so I couldn't examine it interactively!)

The pertinent lines (Linux's dmesg output is WAY too verbose:
"I'm setting voo to 26.  Now I am going to add it to bar.  Having
done that, I am going to divide by three...") are:

[    0.000000] NX (Execute Disable) protection: active
[    0.000000] Memory: 1933912k/1965568k available (2840k kernel code, 
31204k reserved, 1372k data, 412k init, 1054216k highmem)
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000000] Detected 1596.815 MHz processor.
[    0.055590] CPU0: Intel(R) Atom(TM) CPU  330   @ 1.60GHz stepping 02
[    0.148177] Total of 2 processors activated (6441.48 BogoMIPS).
[    3.588418] vesafb: mode is 800x600x16, linelength=1600, pages=7
[    3.588432] vesafb: protected mode interface info at ccfe:0004
[    3.588444] vesafb: pmi: set display start = c00cd00e, set palette = 
c00cd05b
[    3.588454] vesafb: scrolling: redraw
[    3.588465] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
[    3.589066] vesafb: framebuffer at 0xd0000000, mapped to 0xf8280000, 
using 1875k, total 131072k
[    3.628198] Console: switching to colour frame buffer device 100x37
[    3.667295] fb0: VESA VGA frame buffer device
[    4.025707] agpgart-sis 0000:00:00.0: SiS chipset [1039/0671]
[    4.035043] agpgart-sis 0000:00:00.0: AGP aperture is 128M @ 0xf0000000
[    5.814094] sata_sis 0000:00:05.0: version 1.0
[    5.814181] sata_sis 0000:00:05.0: PCI INT A -> GSI 17 (level, low) 
-> IRQ 17
[    5.835469] sata_sis 0000:00:05.0: Detected SiS 1183/966/966L/968/680 
controller in PATA mode
[    6.435391] Atheros(R) L2 Ethernet Driver - version 2.2.3
[    6.501421] bnx2x: Broadcom NetXtreme II 5771x/578xx 10/20-Gigabit 
Ethernet Driver bnx2x 1.70.30-0 (2011/10/25)

(forgive the wrap -- blame the driver coders!)

Obviously, a SiS chipset for the video (and disk interface!).
I'll use that tidbit as a starting point when I build a NetBSD
kernel.  It should also help me avoid an iteration when it comes
to sorting out the disk controller, NIC and wireless.

And, it proves Matt's assertion that I should be able to just
leave a text console running on that port (instead of having
to drag a "terminal" over to it when it craps out).

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!

On 9/18/2014 8:18 PM, Don Y wrote:
> On 9/18/2014 4:22 PM, rickman wrote:
>> On 9/18/2014 6:53 PM, Don Y wrote:
>>> On 9/18/2014 3:12 PM, rickman wrote:
>>>>>>> I don't *think* these have integrated video.  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...
>>>>>>
>>>>>> Can't you boot it with the console being another machine over the
>>>>>> network?
>>>>>
>>>>> Even assuming the NIC is recognized and autoconfigured, it doesn't
>>>>> *appear* that the system is surviving this "scrambled video"
>>>>> event.
>>>>>
>>>>> 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.

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?


>>> 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!


>>> 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.


> [Of course, if the kernel never makes it all the way "up", then
> all bets are off, anyway!]
>
> If the kernel manages to boot, you can still examine these "in core"
> messages AS IF they were entered in the log file (dmesg(8) dumps
> the "system message buffer").  So, in *most* situations, I can
> boot a live CD, wait for the prompt, type "dmesg | more" and examine
> the various messages to see what devices are present, how much
> memory, etc.
>
> If I can get to a command prompt, I can manually mount a thumb
> drive and copy the messages to that medium (dmesg > /mnt/messages.txt)
>
> Or, I can manually bring up a network interface and move stuff
> on/off via that mechanism.
>
> [But, I need access to a command prompt to do so!]
>
>>> 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, 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... ok

Is BSD not at all based on Linux?  Regardless, don't get hung up on the 
terminology.


> *BSD is different from Linux as Linux is different from Windows and
> Windows is different from OSX...
>
> "I don't run Linux"  I also don't run OSX.  So, if OSX could "do it",
> I'd be just as SOL.
>
>> The point is that why can't your version of Linux "distro" do the
>> enumeration?
>
> My NetBSD "live cd" never gets to a command prompt for me to be
> able to *see* what it is saying!  I can watch the first part
> of the boot process... see the first group of devices successfully
> probed (have to look fast because it scrolls by in a jiffy)...
> But, it gets to a point where the screen gets scrambled.
>
> Looking at the screen, I can see much of the previous messages
> (in red-colored text) still present.  But, it is as if the
> HSync has been lost so nothing is clear/readable.
>
> What I want/need to know is the message that it was getting ready to
> emit just as the screen went wonky.   If the kernel is truly crashed,
> then I wouldn't be able to get this message from it even if I had
> a means of typing:
>      dmesg | more
> If just the video is crashed, it is possible that the kernel is
> still functioning (doubtful) but I can't talk to it -- because
> I can't type at the "console" and the network isn't "up".
>
> The solution is to install a simpler kernel (e.g., I can live
> without USB support, network interface, wireless, etc. WHILE
> I am troubleshooting) and then watch to see what the LIKELY
> problem may be.
>
> The fact that the kernel is able to emit messages for a portion
> of the boot process suggests the video can operate as a "dumb
> text console" (because it *is* -- up until that point!).  I
> just need to make sure nothing interferes with it *continuing*
> to do so.
>
> 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?


>>>> I don't think the computers are designed for any OS.  The OS is
>>>> modified
>>>> for the newest processors and chips.  Motherboards are just designed
>>>> for
>>>> target markets.
>>>
>>> Yes, but if a market embraces Windows, then the product effectively
>>> was "designed for Windows".
>>
>> Ok, whatever....  by your definition of "designed for Windows" it has no
>> useful meaning.
>
> It means I am more likely to find a Windows release that will
> run "flawlessly" on this particular set of hardware.  Even if
> the device/driver that is (probably) causing my problem is
> completely proprietary/closed.
>
> OTOH, expecting Linux, *BSD, OSX to run on "any random hardware"
> is a bit of a crap shoot.

I think it means Windows is designed to run on more hardware than the 
various alternative OSs.  The hardware is simply designed to run...

-- 

Rick