new kernel new MSI mb - allota issues
 

first note this pc, booted into win10, plays gta5 decently for a 2nd rate on-sale pc without ever a lock-up (for a few months of ownership) acting as a xbox pc thing.

i'm getting continual lock-ups, ethernet says up for only 10 seconds and some dang supervisor is applying the driver (i compiled all drivers as module but none show in lsmod for thernet). the SATA even throws errors on this thing. USB completely unreliabe - often if i take a flash out i can't put it back in unless i plug a different device in a different port to "wake it up?". SO FAR is the worst period PC i've ever owned or used for 2-3 days !!

the old (being de-commisioned, perhaps not) pc runs 2.6.3x on AMD 1Ghz era (it's extremely reliable btw, though getting sound working was a c&nt as /dev changed and /sys is xxx). the OS: gnu/linux, mostly debian kinda wheezy or jessie

the new PC i TRIED to run same kernel and OS but it appears so far it's not possible. i tried bloated kernel, thin kernel, compiled in, module. every kernel i ran: same mess. i doubt it's because i5 is "true 64" and OS is fully 32bit. i think it's not the i5 or kernel. i compiled on an amd (target i2) and on the i2 (after over a day of waiting / moving files without nothing but usb 1.0 flash). i tried non-smp and smp (i tried thin and thick kernels as i said)

new pc has MSI (good bad brand?) PCMATE (non-"gaming") Z170 (at least intel chip, good) and icore3. pcmate has on-board graphics (why? it's an intel board it's in the intel chip too!), does not use intel for ethernet (rtl driver maybe? broken so far), uses some intel for usb but also MSI added another (i think?) to boast superior usb performance. msi does not share what chip names anything are (for ethernet, sound, sata, video, anything) anywhere and are an asian maker. (before you feel sorry for me: i got it cheap "as-is")

I'm unsure here. Linux 4.16 stable (building as i speak) may help. but it looks to have LESS mfg drivers than 2.6.38. that is: many drivers that worked awesome are now outdated, but very few drivers were added? (that's a question, as i have no clue what's in the SATA or scsi or what drivers)

All I know is I was doing this to run a linux science app i bought that ran on older pc. it came with win and linux versions.

QUESTION:

Q: is MSI motherboard "ok" or no, i need a new board to even think about stability?

Q: is new linux stable on %100 and well supported Intel motherboards (hd audio, hd video)?

Q: should I install that science app on Windows 10. Or should I give QEMU a go? Are drivers getting sparse in kernel because everyone but me is using VM ?

Q: this board runs games ok in win10. but asian MSI is always on my pc "uploading and downloading" (perhaps spying). win10 cortana: also spying. win10: preloads apps your not running which takes like 1/2 of reduing performace which often is "all the time i had to play the game i turned it on for". i really don't care if they spy on gaming of course - but it means i cannot use the pc for anything except to throw at them if i'm not gaming ;)

I already spent 3 days on this only to achieve a severely downgraded system (compiles faster, has vesa, but sata errors wow that's sad) (note in the past that would be nothing, but i'm older and if i spend the time i want it to be spent making or using quality stuffs)

Thank you. would appreciate your direction: go win10 run qemu, no - run 4.16 on pcmate just get my kernel right it will be "stable", or whack: use win10 for gaming_only and upgrade imac

* so far kernel 4.16 seems to "like the board" allot better. for no know reason, 4.16 doesn't say "Z170 support" anywhere

* no more ethernet errors. ethernet problem was something like intel module that manages intel ethernet loading rtl8150 automatically (no way to unload) despite both being compiled as module. still a mystery. the (perhaps wrong / old) rtl8169 "works". what a jack in the box.

* no more SATA errors

* no more SMP errors

* usb / usb flash drive (prolly ok. don't care if it's stable)

* i was wrong about 4.x hardware support having fewer drivers (mostly). while the Z170 is nowhere to select - many areas have more drivers i had just been skipping to keep things simple

so far, 4.x runtime looks look clean and faster. no sound have 0 idea what chipset. (ok, is running small desktop)

wow. it's getting harder it should be getting easier to choose what driver.

it just doesn't seem like Help in configuration and hardware providers really understand there's too much in the world to have people compiling a huge kernel many times just to figure out obscure helplings ;) there's too many choices and the text to choose from is getting more distant. like i need a search bot. you'd think google would help - no it just barfs re-hashes of kernel's config Help not even the Documentation :)

I'm writing this reply running 4.4.132 kernel on a MSI PCMATE that's roughly a year older than a Z170 would be. MSI almost certainly made more than one motherboard model using that chipset, and stopped at least a year ago. The motherboard model is stenciled right on the top of it. Use that to goto the MSI web site and find generic specifications. Use hwinfo, lshw, lspci, lsusb, inxi and/or others once booted to get more detailed info on hardware specifics. You can't expect as an ordinary user to have the kernel tell you it supports any specific chipset, but you can be sure that a chipset as old as that is very well supported by any current Linux distro, which would include the stock kernel and drivers in Stretch, but not those in Wheezy, and likely not those in Jessie.

Any current distro should run a motherboard with Z170 chipset and gfx on the CPU without any issues, choosing appropriate drivers automatically. You shouldn't need to be building anything unless that's simply how you choose to go about your business.

What brand of RAM do you have? Instability could be failing RAM. Have you run memtest overnight? Lifetime guaranteed RAM is no guarantee it won't ever fail. My newest PC is currently down waiting on RMA of DDR4 RAM that died in less than 5 months of part time use.

ok thanks. i've used those tools many times but forget to use the recently. i'm not usually using them because a card maker decided not to tell anyone what chip. it's not supposed to be a secret.

config USB_RTL8150 was the fault. it was selected as 'M' but somehow a kept getting loaded. it would load and unload like every 30 sec. the kernel complained of corruption but reboot wasn't working. it effected SATA (few warnings, is partly usb), USB allot (usb-storage and all else USB - especially plugging/unplugging detection), sound didn't work (i still have to find what chip that is), occasional kernel panics, it was a mess

i still think it was intel pci (express or pro, some use rtl 8150?) which had companion that said it managed features/options for the intel nic. i think that's what somehow kept activating a module i didn't build

like i said i compiled kernel a hand full of times and certain i had all networking drivers (pci, usb) as 'M' and selected only intel and rtl drivers (i didn't know which). it almost had to be the pci driver becuase i usually had usb off (for obvious reasons i was avoiding anything that might be a problem)

Use hwinfo, lshw, lspci, lsusb, inxi. well, yes and no?

i'm actually running an LFS that runs older linux (libc5 and libc6 both). all of those are "kernel specific". i built the latest lscpi that wasn't hacked to force me to use xxxx distro to compile it. however: all it displays is Unknow. it does walk the pci but doesn't help much. also: one can go into /proc and /sys to find strings. (ie, use strings -a). the problem with lspci is it is a hand made table by linux contributors, works only with xxx version of kernel, and newer versions will refuse to compile unless your using ... ubutnu.

ok. first. r8169 driver seems to work for pci ethernet. i'm not doing inet on the particular box because it's legacy linux it's for "lan only".

the 8150 was getting loaded by SOMETHING ELSE - or perhaps getting compiled into kernel despite being selected as 'M' whenever i checked using "make menuconfig". USB_RTL8150 was overwritting in kernel space causing all kinds of hardware and kernel usb/pci issues - the pc barely ran. i'm pretty sure it wasn't a "usb" and i think it was either 1000 or 10000 'M' Intel or Realtek drivers: those are the only ones i picked as 'M'. finally: when i unselected intel the problem went away. it could be some other usb option somewhere but i'm thinking it was intel pci drivers that were behind it all (ie, broken dependecy and broken driver paired).

I'LL HAVE TO SAY IT AGAIN: THIS WAS GETTING HARDER.

in the past FEW kernel drivers overwrote other drivers causing that kind of havoc. (i had one, a parallell port ide backup drive that froze system but didn't cause crashes. but the kernel Help was explicit the driver could do this.). and that's my POINT: nothing anywhere said anything about 8150 becoming a daemon and writing into kernel memory space destroying USB and SATA runtime !!!

IN THE PAST, if your hardware said "IDE" it did so and your only kernel tweak was checking if dma support was enabled for your motherboard. you only needed to select the ide chipset if you were excluding a bug.

TODAY: it's havoc. you can't even find the driver. the toy maker doesn't tell you, they just say "for windows 10", and you have no idea out of the 1000 drivers what might be causing a serious issue?

It's getting harder and it's the hardware makers causing general failure.

have you ever read and adjusted code for walking pci like that's in X11R6? it's not fun. and even if you do it you get mystery strings. the manufacturers aren't doing their "thing" and aren't shipping source code with their hardware.