summaryrefslogtreecommitdiff
path: root/faq/sata_disk_drives/discussion.mdwn
blob: 0b56f23564c6380c677f6790c9c268e466ffe911 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag open_issue_gnumach]]


# IRC, freenode, #hurd, 2013-05-10

    <braunr> what code have you used if any (or is it your own implementation)
      ?
    <youpi> I ended up writing my own implementation
    <braunr> eh :)
    <youpi> the libahci/ahci code from linux is full of linux-specific stuff
    <youpi> it would mean working on gluing that
    <youpi> which woudl rather be just done in block-dde
    <youpi> I was told at fosdem that ahci is not actually very difficult
    <youpi> and it isn't indeed
    <braunr> that's why i usually encourage to use netbsd code

    <braunr> any chance using ahci might speed up our virtual machines ?
    <youpi> they are already using DMA, so probably no
    <youpi> (with the driver I've pushed)
    <youpi> adding support for tagged requests would permit to submit several
      requests at a time
    <youpi> _that_ could improve it
    <youpi> (it would make it quite more complex too)
    <youpi> but not so much actually

    <anatoly> What about virtio? will it speed up?

[[open_issues/virtio]].

    <youpi> probably not so much
    <youpi> because in the end it works the same
    <youpi> the guest writes the physical addresse in mapped memory
    <youpi> kvm performs the read into th epointed memory, triggers an irq
    <youpi> the guest takes the irq, marks as done, starts the next request,
      etc.
    <youpi> most enhancements that virtio could bring can already be achieved
      with ahci
    <youpi> one can probably go further with virtio, but doing it with ahci
      will also benefit bare hardware

    <pinotree> http://en.wikipedia.org/wiki/AHCI
    <youpi> anatoly: aka SATA
    <anatoly> some sort of general protocol to work with any SATA drive via
      AHCI-compatible host controller?
    <braunr> yes

    <youpi> braunr: I may be mistaken, but it does seem ahci is faster than ide
    <youpi> possibly because the ide driver is full of hardcoded wait loops
    <braunr> interesting :)
    <youpi> usleeps here and there
    <braunr> oh right
    <braunr> i wonder how they're actually implemented
    <youpi> so it would make sense to use that on shattrath
    <youpi> a nasty buggy busy-loop
    <braunr> yes but ending when ?
    <youpi> when a given number of loops have elapsed
    <youpi> that's where "buggy" applies :)
    <braunr> ok so buggy implies the loop isn't correctly calibrated
    <youpi> it isn't calibrated at all actually
    <braunr> ew
    <youpi> it was probably calibrated on some 486 or pentium hardware :)
    <braunr> yeah that's what i imagined too
    <braunr> we'll need some measurements but if it's actually true, it's even
      better news


## IRC, freenode, #hurd, 2013-05-11

    <youpi> ah, also, worth mentioning: the AHCI driver supports up to 2TiB
      disks
    <youpi> (as opposed to our IDE driver which supports only LBA28, 128GiB)
    <youpi> supporting more than 2TiB would require an RPC change, or using
      bigger sectors
    <youpi> (which wouldn't be a bad idea anyway)
    <braunr> i think we should switch to uint64_t addressable vm_objects
    <braunr> which would allow to support large files too
    <youpi> braunr: yep


## IRC, freenode, #hurd, 2013-05-13

    <braunr> the hurd, running on vbox, with a sata controler :)
    <braunr> hum, problem with an extended partition
    <anatoly_> qemu/kbm doesn't have sata controller, am I right?
    <braunr> anatoly: recent versions might
    <braunr> http://wiki.qemu.org/Features/AHCI
    <braunr> www.linux-kvm.org/wiki/images/7/73/2011-forum-ahci.pdf
    <anatoly> braunr: found first link, too. Thanx for the second one
    <braunr>
      http://git.qemu.org/?p=qemu.git;a=blob;f=hw/ide/ahci.c;h=eab60961bd818c22cf819d85d0bd5485d3a17754;hb=HEAD
    <braunr> looks ok in recent versions
    <braunr> looks useful to have virtio drivers though

[[open_issues/virtio]].

    <anatoly> virtio is shown as fastest way for IO in the presentation
    <anatoly> Hm, failed to run qemu with AHCI enabled
    <anatoly> qemu 1.1 from debian testing
    <anatoly> youpi how do run qemu with AHCI enabled?


## IRC, freenode, #hurd, 2013-05-14

    <anatoly> can somebody ask youpi how he runs qemu with AHCI please?
    <gnu_srs> I think he used vbox?  Did not find any AHCI option for kvm
      (1.1.2-+dfsg-6)
    <anatoly> gnu_srs: http://wiki.qemu.org/ChangeLog/0.14#IDE_.2F_AHCI
    <anatoly> but it doesn't work for me the same version of kvm
    <braunr_> anatoly: have you checked how the debian package builds it ?
    <anatoly> braunr: mach sees AHCI device
    <braunr> oh :)
    <anatoly> the problem is in last option "-device
      ide-drive,drive=disk,bus=ahci.0"
    <anatoly> lvm says 'invalid option'
    <braunr> anatoly: can you give more details please ?
    <braunr> lvm ?
    <anatoly> s/lvm/kvm
    <braunr> i don't understand
    <braunr> how can mach probe an ahci drive if you can't start kvm ?
    <anatoly> I ran it without last option
    <braunr> then why do you want that option ?
    <anatoly> But, actually I entered command with mistake. I retried it and it
      works. But got "start ext2fs: ext2fs: device:hd0s2: No such device or
      address"
    <anatoly> Sorry for confusing
    <braunr> that's normal
    <braunr> it should be sd0s2
    <bddebian2> Right because the device names are different
    <braunr> be aware that gnumach couln't see my extended partitions when i
      tried that yesterday
    <braunr> i don't know what causes the problem
    <anatoly> Yeah, I understand, I just note about it to show that it works
    <braunr> :)
    <anatoly> And I was wring
    <anatoly> s/wring/wrong
    <braunr> is that the version in wheezy ?
    <anatoly> I'm using testing, but it's same
    <braunr> great
    <braunr> the sceen.net VMs will soon use that then
    <anatoly> I don't have extended partions
    <anatoly> Booted with AHCI! :-)
    <anatoly> It freezes while downloading packages for build-essential
      fake-root dependencies with AHCI enabled
    <youpi> anatoly: is the IRQ of the ahci controller the same as for your
      ethernet device? (you can see that in lspci -v)
    <anatoly> youpi: will check
    <anatoly> youpi both uses IRQ 111
    <anatoly> s/111/11
    <braunr> aw
    <youpi> anatoly: ok, that might be why
    <youpi> is this kvm?
    <youpi> if so, you can set up a second ahci controler
    <youpi> and attach devices to it
    <youpi> so the irq is not the same
    <youpi> basically, the issue is about dde disabling the irq
    <youpi> during interrupt handler
    <youpi> which conflicts with ahci driver needs


## IRC, freenode, #hurd, 2013-05-15

    <anatoly> youpi: yes, it's kvm. Will try a second ahci controller

    <Slex> I read recentrly was added ahci driver, is it in userland or
      kernel-land?
    <gnu_srs> kernel-land the change was in gnumach


## IRC, freenode, #hurd, 2013-05-18

    <youpi> about the IRQ conflict, it's simply that both dde and the ahci
      driver need to disable it
    <youpi> it needs to be coherent somehow


## IRC, freenode, #hurd, 2013-05-20

    <anatoly> gnu_srs: kvm -m 1G -drive
      id=disk,file=<path_hurd_disk_img>,if=none,cache=writeback -device
      ahci,id=ahci-1 -device ahci,id=ahci-2 -device
      ide-drive,drive=disk,bus=ahci-2.0
    <anatoly> who knows what does "ich9-ahci.multifunction=on/off" parameter
      for kvm's ahci device mean?
    <anatoly> well, I was a bit incorrect :-) The options is relative to PCI
      miltifunction devices
    <anatoly> s/options is relative/options relates


## IRC, freenode, #hurd, 2013-05-24

    <anatoly> I don't see freezes anymore while downloading packages with AHCI
      enabled
    <youpi> anatoly: by fixing the shared IRQ ?
    <anatoly> youpi: yes, I added second AHCI as you suggested
    <youpi> ok
    <youpi> so it's probably the shared IRQ issue
    <anatoly> NIC and AHCI have similar IRQ when only one AHCI is enabled
    <anatoly> according lspci output
    <youpi> yes


## IRC, freenode, #hurd, 2013-06-18

    <braunr> youpi: is there a simple way from hurd to check interrupts ?
    <youpi> what do you mean by "check interrupts" ?
    <braunr> if they're shared
    <youpi> I still don't understand :)
    <braunr> i'm setting up sata
    <youpi> ah, knowing the number
    <braunr> yes
    <youpi> you can read that from lspci -v
    <braunr> ok
    <braunr> thanks
    <braunr> hum
    <braunr> i get set root='hd-49,msdos1' in grub.cfg when changing the
      device.map file to point to sd0
    <youpi> hum
    <braunr> i wonder if it's necessary
    <braunr> i guess i just have to tell gnumach to look for sd0, not grub
    <braunr> youpi: the trick you mentioned was to add another controler, right
      ?
    <youpi> yes
    <braunr> ok
    <braunr> youpi: looks fine :)
    <braunr> and yes, i left hd0 in grub's device.map
    <braunr> although i have lots of errors on hd0s6 (/home)
    <braunr> youpi: there must be a bug with large sizes
    <braunr> i'll stick with ide for now, but at least setting sata with
      libvirt was quite easy to do
    <braunr> so we can easily switch later


## IRC, freenode, #hurd, 2013-10-22

    <teythoon> youpi: do I need to do anything to enable the ahci driver?
      gnumach 1.4 should include it, right?
    <youpi> it should, yes
    <youpi> make sure to put your board in ahci mode, not raid mode
    <youpi> (and not ata mode)
    <teythoon> youpi: hm, I will try to do so
    <teythoon> youpi: does the driver print anything to the console?
    <youpi> teythoon: yes, AHCI SATA 00:04.0 BAR 0xfebf1000 IRQ 11
    <teythoon> youpi: well, the bios has two modes of operation, 'raid' and
      'ide', I selected 'ide'
    <youpi> ergl
    <teythoon> youpi: hm, I think my board has no ahci controller, linux uses
      the sata_via module to talk to it :/
    <youpi> ah :/


# IRC, freenode, #hurd, 2014-02-05

    <braunr> teythoon: i don't completely trust the driver
    <teythoon> oh ?
    <braunr> it doesn't work on my laptop, and i had a failure once on a "big"
      partition of 128G
    <teythoon> hm
    <teythoon> my hardware does not implement ahci, but in qemu it works fine
      for me
    <braunr> well qemu is the only supported "hardware" 
    <teythoon> but then my partitions are not that big
    <youpi> braunr: no, it does work on my laptop too
    <braunr> ok


# IRC, freenode, #hurd, 2014-02-12

    <braunr> youpi: hum, sorry to ask but how do you use qemu to provide sata ?
    <youpi> braunr: there's an important trick: getting it on another IRQ than
      the eth0 board :/
    <youpi> -device ahci,id=ahci1
    <youpi> for nothing
    <youpi> -device ahci,id=ahci2
    <youpi> -drive id=root,file=/dev/${HDA}7,cache=writeback,if=none
    <youpi> -device ide-drive,drive=root,bus=ahci2.1
    <braunr> ok that's close enough to what i have
    <braunr> but
    <braunr> i'm using /dev/sda as the backend
    <braunr> instead of a regular file
    <braunr> sda already containing a regular debian linux system
    <braunr> and grub2 can't boot because it seems to fail reading the
      partition table
    <braunr> it works perfectly when accessing it as an ide disk though
    <braunr> youpi: do you see any reason why grub would fail with ahci ?
    <braunr> also, why ahci2._1_ instead of 0 ?
    <braunr> youpi: fyi, the cd installer always booted fine here, both on my
      workstation and my laptop, i did about 50 tries on each machine
    <braunr> the graphical mode doesn't seem to work though
    <braunr> youpi: fyi2 the grub related issue i'm having is
      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692249
    <youpi> I'm using .1 because I have a /boot .0 before the / .1 :)
    <braunr> humm
    <braunr> you have two drives ?
    <youpi> braunr: (cd installer): you mean, even in semi-graphical mode?
    <braunr> one for /boot and the other for / ?
    <youpi> I have 3 actually :)
    <braunr> youpi: no, xorg
    <braunr> ok i se
    <braunr> see
    <youpi> (cd installer) I'm talking about the working ones :)
    <youpi> I know xorg does not boot
    <braunr> ok
    <braunr> so apparently, adding ,boot=on to the -drive parameter did the
      trick
    <youpi> k
    <braunr> and now, i have a hurd system running from /dev/sda5 (the real
      disk) in qemu
    <youpi> for the pseudo-graphical console, I guess his monitor is too dumb
      to be able to display 640x400
    <braunr> possible
    <youpi> most probably because no OS uses that any more nowadays :/
    <youpi> (and that won't get better)
    <braunr> so now i can debug ahci on my laptop using that :)

    <braunr> youpi: is there a known limit to the size of an ahci drive in the
      gnumach driver ?
    <youpi> in the driver itself, it's simply lba48
    <youpi> but the mach interface uses 32bit sector number
    <youpi> thus 2TB limit
    <braunr> that's plenty :)
    <youpi> I have a 2TB drive :)
    <youpi> so it won't be plenty for long
    <braunr> 2TB for your hurd system ?
    <youpi> no, for my backups etc.
    <braunr> i meant plenty for our hurd instances
    <youpi> but there could have been a hurd vm there
    <youpi> and not necesseraly below 2TiB

    <braunr> hm, the installer doesn't detect existing partitions on an ahci
      drive :/


## IRC, freenode, #hurd, 2014-02-13

    <braunr> youpi: looks like linux has trouble handling my ahci drive without
      ioapic/msi
    <braunr> no wonder gnumach can't either
    <youpi> erf