Errors in Boot Log for Dell M300

The more I think about this problem,the more I am leaning toward SATA power management issue. The internal SSD is really just an SD card so it would take less than 5V to run.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

This is so aggravating to try to diagnose. My one M300 that I've loaded several packages on seems to boot off of SSD and remain stable, so I switched to my other one that is pretty much a bare bones installation. Now I can't make it fail either. Arrrg! One other data point that I don't know if I ever mentioned - when I was experiencing the problem I could have a USB drive inserted (probably a rootfs drive), plug in the power, and then remove the drive while the light was flashing and everything would be ok. I want to do more experimenting, but I can't make it be unstable anymore.

On a possibly unrelated note, what does it mean when the light goes from flashing white, to solid orange, to solid white during boot?

-JT

JT,

> Arrrg! One other data point that I don't know if
> I ever mentioned - when I was experiencing the
> problem I could have a USB drive inserted
> (probably a rootfs drive), plug in the power, and
> then remove the drive while the light was flashing
> and everything would be ok.

That's even more a reason perhaps we should look at the power management. The problem with DTS regulator (how we power the drive) is that I don't know which GPIO is for SATA or USB power without GPLL source.

When I have time, I will brute force it to see if which one is.

> I want to do more
> experimenting, but I can't make it be unstable
> anymore.

I think if the USB is plugged in like Mike has tried, it is stable.

> On a possibly unrelated note, what does it mean
> when the light goes from flashing white, to solid
> orange, to solid white during boot?
>

That's the boot sequence. Flashing white means booting, orange when the kernel stars, solid white is when the kernel has booted successfully. And then depending on what on the rootfs, it would take from 10s to 20s or more to complete.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> > I want to do more
> > experimenting, but I can't make it be unstable
> > anymore.
>
> I think if the USB is plugged in like Mike has
> tried, it is stable.

Just to be clear, with or without any USB drive plugged in it boots just fine and remains stable. I have no idea why it's stable now and wasn't before

> > On a possibly unrelated note, what does it mean
> > when the light goes from flashing white, to solid
> > orange, to solid white during boot?
> >
>
> That's the boot sequence. Flashing white means
> booting, orange when the kernel stars, solid white
> is when the kernel has booted successfully. And
> then depending on what on the rootfs, it would
> take from 10s to 20s or more to complete.

That's interesting. One of M300s does the flashing white, solid orange, solid white thing while the other just goes right from flashing white to solid white.

That's interesting, the one I've been working on goes flashing white, solid orange, solid white, as it is supposed to.

My units, all of them boot up with white LED. Never seen them display a different color.

Kinda wish the LED hole was in the front.....but then again that could be annoying.

I think perhaps some envs difference could cause different LED behavior.

In the DTS, we could set set default for the white LED when the kernel booted. Ususally we would want to do that. But since we manage it directly in the /etc/rc.local, I did not bother to change the DTS.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> I did not bother to change the DTS.

If it boots, then who cares about the colors while booting. Plus it's in the back so not something I would generally pay attention to as I don't face the butt of the device towards me while booting.

Related, I have researched if anyone made a USB LED module that you could program to act as a boot monitor / network monitor for this very device. Did not find any that was not made for application specific usage or for industrial devices.

> If it boots, then who cares about the colors while
> booting. Plus it's in the back so not something I
> would generally pay attention to as I don't face
> the butt of the device towards me while booting.

True, if it boots :)

OTOH, the LED color is quite informative when the box does not boot, and then, you just happen to have your only serial module converter unavailable, i.e. being plugged into some other box.

So to do it right, we need to set it up in /etc/rc.local and /etc/init.d/halt like I mentioned in the rootfs release.

Quote

- see LED controls in /etc/rc.local, and /etc/init.d/halt

This box came late in our forum history, so I can't recall if I modified these scripts to include M300 names.

/etc/rc.local should have this:

if [ -d /sys/class/leds/m300:white:sys ]; then
   echo default-on  > /sys/class/leds/m300:white:sys/trigger 
   echo none        > /sys/class/leds/m300:orange:sys/trigger
fi

And /etc/init.d/halt should have this:

if [ -d /sys/class/leds/m300:white:sys ]; then
   echo none   > /sys/class/leds/m300:white:sys/trigger 
fi

So the LED is clear properly during shutdown, and will flash white during power up, and becomes orange at proper time.

If after you've set up the LED in these 2 scripts, and it still does not flash properly then I think it might worth looking into the u-boot envs.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I'll have to check my two rc.local scripts. They should be identical, but clearly the behavior is different on my two M300s.

My second M300 does not have the m300 parameters in either rc.local or halt scripts. Yet, the light displays the expected sequence during boot. The other M300 does not have them but I have not watched the light during boot. I recall seeing Bohdi's not about light controls, but did not check them, and would not have known what to look for. I'll add the suggested changes. I'm guessing these will be in the rootfs going forward.