Installing FreeBSD 10.0 on Jetway board fails?

A

anti

I am trying to install FreeBSD 10.0 on this board on a CF (Compact Flash): Jetway NF9HQL-525.

- Embedded Intel Atom D525 @ 1.8GHz, dual-core w/Hyper-Threading Technology
- 4 x Realtek RTL8111E Gigabit LAN Ports
- On-board Bootable CompactFlash (CF) Slot
- Supports up to 4GB DDR3 SODIMM memory
- On-board 12V DC-DC Power Converter
- PCI-E x 1 and Mini PCI-E Expansion slot; supports mSATA
- Thin Mini-ITX Form Factor

I the installation got stuck and stops the step shown in the attached image.


Any advice please?
 

Attachments

  • IMG-20140209-WA0009.jpg
    IMG-20140209-WA0009.jpg
    103.1 KB · Views: 751
Interesting. The problem is with one of the disk interfaces. What "disk" are you using to install on (it might be a CD or mSATA solid-state disk)? GIven that the device comes up as ada0, it might be just about anything. Have you ever run an earlier version of FreeBSD (such as 9.x) on this? Can you, for starters, disconnect all disks except the one you are installing on, and try again? Or how about taking that disk out, and trying a boring normal (spinning rust) disk on the SATA connector?

I hate to even suggest it, but it might help distinguish between broken hardware, and an incompatibility with FreeBSD: Try installing Linux, on exactly the same setup.
 
Debian and FreeBSD 9.0 already tested and work. FreeBSD 9.2 and 10.0 don't work and show same issue!
ralphbsz said:
disconnect all disks except the one you are installing on, and try again? Or how about taking that disk out, and trying a boring normal (spinning rust) disk on the SATA connector?
Try installing Linux, on exactly the same setup.
Click to expand...

I am using CF as a main storage, no other disk is installed.
 
We know it's not the Atom CPU itself ... the stuff I type here is transferred through a Jetway NF99FL board, with the same Atom in it. We know it's not the IO chip on Jetway's Atom boards, since I have the same chip. I think the problem must be the CF (sorry, I wrote "CD" above, meant to write CF). My only idea is: Disconnect the CF, find some SATA disk and a cable, try it with that. If that works, you have verified that at least your board fundamentally works. The next step would be to use a different CF (perhaps different brand).

When I used to run OpenBSD on a Soekris box (and booting from CF), I learned that not all CFs are created equal. Some are really crappy, and are designed and tested only for the workloads that occur in digital cameras. I forgot what brand CF I used initially, but it had more errors than a wild dog has fleas. Other types of CF can handle a normal file system workload OK, without problems. I think I ended up with a SanDisk professional model (it would take me 10 minutes of digging in a bin with old parts to find out exactly). So my mistrust of CF is why I keep suggesting that you try a more "normal" disk first.
 
ralphbsz said:
We know it's not the Atom CPU itself ... the stuff I type here is transferred through a Jetway NF99FL board, with the same Atom in it. We know it's not the IO chip on Jetway's Atom boards, since I have the same chip. I think the problem must be the CF (sorry, I wrote "CD" above, meant to write CF). My only idea is: Disconnect the CF, find some SATA disk and a cable, try it with that. If that works, you have verified that at least your board fundamentally works. The next step would be to use a different CF (perhaps different brand).

When I used to run OpenBSD on a Soekris box (and booting from CF), I learned that not all CFs are created equal. Some are really crappy, and are designed and tested only for the workloads that occur in digital cameras. I forgot what brand CF I used initially, but it had more errors than a wild dog has fleas. Other types of CF can handle a normal file system workload OK, without problems. I think I ended up with a SanDisk professional model (it would take me 10 minutes of digging in a bin with old parts to find out exactly). So my mistrust of CF is why I keep suggesting that you try a more "normal" disk first.
Click to expand...

Most likely the issue is CF related as you said. But how can we explain that FreeBSD 9.0 worked on it but not 10.0 nor 9.2?
 
anti said:
Most likely the issue is CF related as you said. But how can we explain that FreeBSD 9.0 worked on it but not 10.0 nor 9.2?
Click to expand...

Bad luck? Maybe there is one bad block on the CF, and the error handling somewhere in the software stack (CF firmware, SATA adapter firmware, OS driver) is so crappy that this one particularly bad block causes a total freeze of the ATA layer. And maybe Linux and FreeBSD 9.0 didn't hit that block, but 9.2 and 10.0 did. I know this is a bit far-fetched, but it is certainly possible.
 
anti said:
Most likely the issue is CF related as you said. But how can we explain that FreeBSD 9.0 worked on it but not 10.0 nor 9.2?
Click to expand...
It's also possible you've hit a regression bug. That doesn't happen often but it's certainly a possibility. Have you tried 9.1? Just to rule out where exactly things might have gone wrong.
 
SirDice said:
anti said:
Most likely the issue is CF related as you said. But how can we explain that FreeBSD 9.0 worked on it but not 10.0 nor 9.2?
Click to expand...
It's also possible you've hit a regression bug. That doesn't happen often but it's certainly a possibility. Have you tried 9.1? Just to rule out where exactly things might have gone wrong.
Click to expand...
9.1 works! :\
 
Two options I can see. Either it is really a regression bug. Or it is bad luck, and the CF (or the CF/MoBo combination) is unreliable, and it is giving you symptoms that are compatible with regression. The only way I know to find out: Try it a few more times, with 9.1 and 9.2. If you find results that are absolutely consistent (9.1 works, 9.2 doesn't), then you know it's a software problem.

Asking you to do this is unfortunately somewhat rude, since this would be a very time-consuming test. You could even invest more time, and try different types of disks (SATA, USB, different model CF cards), and try to narrow it down even more. If you really want this problem to get fixed, you probably have to contribute to the cause by providing very accurate diagnostic information, so someone interested in this piece of code has all the data they need to fix it.
 
I have hit this just now with the same hardware, that is currently running pfSense 2.1.5 FreeBSD 8.3. I am attempting to upgrade to pfSense 2.2-RC FreeBSD 10.1 and get the same type of "disk" errors from 2 boxes using exactly the same hardware - Jetway board and 4GB CF card.
I am a frequent contributor to the pfSense project, but have not been much upstream to FreeBSD! What should I do to progress this? Or is it just that these Jetway 525 boards do not work with FreeBSD 9.2 and later, so ditch them?
Is support intended to be removed for these, or is it just an accidental regression?
 
Probably just an accidental regression. You should try to test the latest FreeBSD releases (9.3, 10.1) on this board to see if they have the same problems. If they do, file a bug report.
 
I had been enthusiastic to try to track down exactly where things went wrong for this hardware. But I was only using it in 1 install and have replaced it with new hardware that happily runs FreeBSD 10.1 pfSense 2.2.*. The Jetway now sits in the cupboard. Maybe I can use it for something or other with another *n*x flavor, but it is no use for FreeBSD and from the rush of posts here from others saying "me too", "please fix it", it seems that no-one much else cares.
 
I just did 2 similar installations yesterday where I had troubles with SATA controller in AHCI mode. Switching to IDE mode saved the day.
 
Jetway boards are a real hit and miss. Many of them have problems for example with the more exotic USB peripherals that make the boards lock up on boot. I have a Jetway ATOM board as my firewall, it works ok in a very stripped down configuration. I wouldn't try to use it for a multimedia PC though.
 
You must log in or register to reply here.
Back
Top