1 |
On Friday 21 January 2011 21:05:30 meino.cramer@×××.de wrote: |
2 |
> Mark Knecht <markknecht@×××××.com> [11-01-21 20:36]: |
3 |
> > On Fri, Jan 21, 2011 at 11:16 AM, Volker Armin Hemmann |
4 |
> > <volkerarmin@××××××××××.com> wrote: |
5 |
> > <SNIP> |
6 |
> > |
7 |
> > >> I'm happy to be corrected (by Volker I'm sure) but that's my |
8 |
> > >> guess |
9 |
> > >> as to what you're seeing. |
10 |
> > > |
11 |
> > > you are confusing bios calls and bios programming chips as.... also |
12 |
> > > - is there any good reason to use IDE mode? Any? At all? |
13 |
> > |
14 |
> > I don't believe I'm 'confusing bios calls with bios programming'. The |
15 |
> > BIOS can do whatever it wants to in programming the chips as long as |
16 |
> > grub can still find the kernel. After grub finds the kernel the kernel |
17 |
> > is free to override whatever chip programming the BIOS has done and |
18 |
> > reprogram the chips as it sees best. |
19 |
> > |
20 |
> > I think the issue meino possibly has is that he likely didn't include |
21 |
> > an Int13 type driver in the kernel or most likely his system would |
22 |
> > have booted like it did in the _very_ old days. |
23 |
> > |
24 |
> > I agree that there isn't any good reason I know of to use IDE mode |
25 |
> > unless the other modes the BIOS provides don't work. |
26 |
> > |
27 |
> > I cannot get into my Asus BIOS at the moment, but as I remember it |
28 |
> > Asus gave me something like |
29 |
> > |
30 |
> > IDE |
31 |
> > AHCI |
32 |
> > AHCI + compatibility |
33 |
> > |
34 |
> > IIRC I had to use the last one to get mine to boot but I may be wrong |
35 |
> > about that. I only mention this as meino is also using Asus so he |
36 |
> > might look for similar options. |
37 |
> > |
38 |
> > - Mark |
39 |
> |
40 |
> Hi, |
41 |
> |
42 |
> I switched the BIOS from IDE (kernel is using AHCI) to AHCI (kernel |
43 |
> uses AHCI). The dmesg says (I did a dmesg | grep -i ahci now, previous |
44 |
> check was done with dmesg | grep AHCI only): |
45 |
> |
46 |
> solfire:/root>dmesg | grep -i ahci |
47 |
> ahci 0000:00:11.0: version 3.0 |
48 |
> *0* ahci 0000:00:11.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 |
49 |
> *1* ahci 0000:00:11.0: irq 78 for MSI/MSI-X |
50 |
> *2* ahci 0000:00:11.0: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA |
51 |
> mode *3* ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio |
52 |
> slum part scsi0 : ahci |
53 |
> scsi1 : ahci |
54 |
> scsi2 : ahci |
55 |
> scsi3 : ahci |
56 |
> scsi4 : ahci |
57 |
> scsi5 : ahci |
58 |
> ahci 0000:07:00.0: PCI INT A -> GSI 44 (level, low) -> IRQ 44 |
59 |
> *4* ahci 0000:07:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA |
60 |
> mode *5* ahci 0000:07:00.0: flags: 64bit ncq pm led clo pmp pio slum part |
61 |
> *6* ahci 0000:07:00.0: setting latency timer to 64 |
62 |
> scsi6 : ahci |
63 |
> scsi7 : ahci |
64 |
> |
65 |
> For me bare eye this looks like the kernel ha switched all seven ports |
66 |
> to AHCI. Lines marked with "*n*" are still a riddle to me. May be |
67 |
> Volker will give us some enlightment? |
68 |
> Why is line *1* of the first block missing in the second block, |
69 |
> Volker? Why is line *2* talking about "0x3f" while line *4* is using |
70 |
> "0x3", Volker? Why differ line *5* from line *3*, Volker? What does |
71 |
> all these flags mean? |
72 |
> |
73 |
|
74 |
you know - there are websites for that. Google is your friend. But even a |
75 |
glance would reveal to you: |
76 |
two different chips. |
77 |
One using MSI for interrupts the second not. |
78 |
|
79 |
> I find this interesting: |
80 |
> |
81 |
> http://www.linuxquestions.org/questions/linux-hardware-18/6-tips-for-improvi |
82 |
> ng-hard-drive-performance-835034/ |
83 |
|
84 |
it is a start. But the first link there... just saying.. there is no magically |
85 |
correct value for stride or chunk. |
86 |
|
87 |
Oh and if you are using AFT drives make sure the partitions are set up |
88 |
correctly. |
89 |
|
90 |
Also: |
91 |
https://ata.wiki.kernel.org/index.php/Main_Page |