1 |
Michael Mol wrote: |
2 |
> Play with your BIOS settings. Look for things like legacy USB support. |
3 |
> Also, double-check that all the relevant USB drivers (UHCI, EHCI, |
4 |
> XHCI, HID, etc) are either built-into the kernel, or are loaded as |
5 |
> modules. Consider rebuilding your kernel. Just because one processor |
6 |
> has a superset of the instructions of the other doesn't mean there may |
7 |
> not be other compatibilities. Some time back, a thread on here |
8 |
> discussed how to find out what -march=native becomes, in terms of |
9 |
> -march and a bunch of other parameters. I've noticed parameters like |
10 |
> cache line sizes and cache sizes, among a couple others. I imagine a |
11 |
> bungling of, e.g., cache line sizes could break code that has heavy |
12 |
> dependency on data locality and/or memory models; it might have broken |
13 |
> your USB drivers, for example. But, really, I think BIOS settings and |
14 |
> driver presence are the more likely culprit. |
15 |
|
16 |
Here it is: |
17 |
|
18 |
gcc -Q --help=target -march=native |
19 |
|
20 |
I agree tho that checking those BIOS setting is a good start. If that fails, boot a CD or something, chroot in, do a emerge -e system. Maybe make some corrections to the kernel then try booting. Oh, I'd rebuild the input drivers to, mouse and keyboard. Check the USE flags too. I'm not sure what all options they have. |
21 |
|
22 |
|
23 |
Dale |
24 |
|
25 |
:-) :-) |
26 |
|
27 |
-- |
28 |
I am only responsible for what I said ... Not for what you understood or how you interpreted my words! |