Hi - On 2016-10-17 at 14:36 "Ronald G. Minnich" <[email protected]> wrote: > In qemu, it still shows the device as having zero bytes. > But it does find it.
I'll take this whole patch set as is, since you all are basically the maintainers of it and you're actively fixing it up. Merged to master at bd57db6e170d..e68a8934c7fd (from, to] You can see the entire diff with 'git diff' or at https://github.com/brho/akaros/compare/bd57db6e170d...e68a8934c7fd Here's a few other things to either fix in the future or keep in mind: 1) This: @@ -211,16 +209,38 @@ static int prid = 1; +/* ALL time units in this file are in milliseconds. */ +static uint32_t ms(void) +{ + return (uint32_t)(epoch_nsec() / 1048576); +} This should probably be epoch_nsec() / 1000000. 2) Krefs Any use of krefs in ported Plan 9 code will need looked at. I noticed this: +static void releasedrive(struct kref *kref) +{ + printk("release drive called, but we don't do that yet\n"); +} + Usually, it'll require a rewrite / restructuring of the code. Just FYI. 3) waserror: static void esleep(int ms) { - struct proc *up = externup(); + ERRSTACK(2); if (waserror()) return; - tsleep(&up->sleep, return0, 0, ms); + kthread_usleep(ms * 1000); poperror(); } The rules for waserror: - Have as many ERRSTACK as there are waserrors (so 1, not 2). It's not going to crash, but it'll consume more stack space. - Every path from a waserror needs either a poperror or a nexterror. This is different than Plan 9, so it is always something that needs attention during a driver port. In the example code (and in other places), the error path does not have a poperror or nexterror. It looks like you are trying to catch the error and just return. To do so: if (waserror()) { poperror(); return; } 4) Magic unicode characters + printd("ahci: %s: resetdisk: %s → %s\n", Plan 9 (and Go) is way to clever with their fancy characters. 5) PCI phantoms + /* In earlier days bus address 0xff caused problems so we only iterated to + * PCI_MAX_BUS - 1, but this should no longer be an issue. + * Old comment: phantoms at 0xff */ Your changes are fine. From what I recall, we had machines where we'd see devices appear multiple times in the PCI space, once at their 'real' location, and another time on bus 0xff. I don't know exactly what the phantoms are, though this has a few clues: https://pcisig.com/sites/default/files/specification_documents/ECN-alt-rid-interpretation-070604.pdf Barret -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
