[[!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