• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 17 replies
  • Subscribers 136 subscribers
  • Views 18124 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Samsung Chromebook; Serious stability issues when following graphics and compute guide

John Chadwick

Brief version: How can I debug my Chromebook woes when trying to run kernel-next with the Mali drivers?

I followed this guide: Graphics and Compute Development on Samsung Chromebook It worked, but I'm left with an incredibly unstable system. I'm running a Samsung Chromebook, model number SNOW FREMONT A-E 0878.

A list of stability issues so far:

  • Most importantly, all of the MMC bus seems to give out rather soon after booting up, no matter what. All I/O starts to fail and after a while of waiting I see messages from the kernel reporting timeouts on the MMC bus, and then the system gets locked up.
  • VT1 will typically start to get flooded with something like "udevd[187]: timeout: killing '/sbin/modprobe -bv sdio:c00v02DFd912A' [262]" until it eventually locks up or throws a kernel panic message.
  • The system will often run long enough to actually let me do something. I can connect to wifi, but briefly after doing so, I will usually see the mwifiex_sdio driver hit a time out, followed by a card reset, at which point the device disappears from the system.
  • Sometimes it doesn't even boot. It just stops during the upstart sequence, before any of the other VTs are created, and then it eventually throws some sort of kernel panic. The actual kernel panic message is pushed off screen by the remainder of the data.

I'm even sure there's more, but for now that should give a good idea of what's up: ridiculous instability. I might be able to throw the image on a USB drive and use a USB wifi adapter and skate by some of this, but that's really not a sufficient solution. Given that and the incredible unlikeliness that anyone here has already had or is having this issue, I'd really like it if someone could tell me how to debug these issues as I don't have any clue how to approach it. I have a bit of familiarity with the Linux kernel and a ton with C, but not a darn clue how I'd go about debugging Linux running on a Chromebook.

Hope this is related enough to be discussed here - I certainly don't know where else to discuss problems with this guide.

Parents
  • 0 in reply to Krishnaraj Bhat

    The hardware modifications seems a little more hardcore than I feel like risking.  You can if you like run your own u-boot using the second bootloader method.  I got it working, and you can read the steps I took here in this discussion as they differed from the "official" steps.

    That said-- people seem to be building the mainline kernel instead of kernel-next, which I don't think anyone has checked changes into for two months.  I'm wondering if this might be the way to go.  (also see this thread)  If no one gives it a try, I am thinking of giving it a shot by taking mainline, applying the patches, and then seeing what happens

    ft

    Update:  Hmm, I'm not seeing much gpu support-- there's no /drivers/gpu/arm directory in mainline, making it kind of hard to do the changes to mali_kbase_config_chromebook.c, considering that file doesn't exist. Looks like framebuffer only. I added in the gpu driver and I'm trying to see if it can be shoehorned into place... but I invite anyone who might know more than I do to chime in.  Can the mali open source device driver be dropped into 3.12?

Reply
  • 0 in reply to Krishnaraj Bhat

    The hardware modifications seems a little more hardcore than I feel like risking.  You can if you like run your own u-boot using the second bootloader method.  I got it working, and you can read the steps I took here in this discussion as they differed from the "official" steps.

    That said-- people seem to be building the mainline kernel instead of kernel-next, which I don't think anyone has checked changes into for two months.  I'm wondering if this might be the way to go.  (also see this thread)  If no one gives it a try, I am thinking of giving it a shot by taking mainline, applying the patches, and then seeing what happens

    ft

    Update:  Hmm, I'm not seeing much gpu support-- there's no /drivers/gpu/arm directory in mainline, making it kind of hard to do the changes to mali_kbase_config_chromebook.c, considering that file doesn't exist. Looks like framebuffer only. I added in the gpu driver and I'm trying to see if it can be shoehorned into place... but I invite anyone who might know more than I do to chime in.  Can the mali open source device driver be dropped into 3.12?

Children
No data