<damo22>acpi: creating the ACPI filesystem tree: Operation not permitted <damo22>ext2fs: part:2:device:sd0: warning: FILESYSTEM NOT UNMOUNTED CLEANLY; PLEASE fsck <damo22>ext2fs: part:2:device:sd0: warning: MOUNTED READ-ONLY; MUST USE `fsysopts --writable' <damo22>Hurd server bootstrap: ext2fs[part:2:device:sd0] exec startup <damo22>i think this could be acpi trying to grab ioports <damo22>aha acpi_get_num_tables calls /dev/mem <damo22>but there is no /dev so it needs to use mem device <damo22>start acpi: acpi pci rumpdisk Kernel is already driving a SATA device, skippingprobing disks <damo22>Hurd server bootstrap: ext2fs[part:2:device:sd0] exec startup proc auth. <damo22>youpi: if i device_open "acpi", can i call acpi translator RPCs on that device or do i need to implement a custom device_* RPC ? <youpi>damo22: you can make device_open return whatever port you like, so it can be a port on which the acpi translator RPCs work <damo22>im getting very close to having rump ask acpi for irq <damo22>but it depends on previous patches <damo22>youpi: why are we not using the device called "pci" in pci-userspace for rump? it could be simplified such that we always require a pci-arbiter master to be running before running a rump driver? <damo22>wouldnt that also give us ability to run a subhurd using a real disk controller? <youpi>it's more flexible to first try to open /servers/pci <youpi>but reverting to the pci device can be useful, yes <damo22>no we are using libpciaccess in pci-userspace <damo22>it does not open the pci device as a client <youpi>yes we use libpciaccess, but isn't that doing that? <damo22>ok so clients using pci should use libpciaccess always then <damo22>ok so the answer is we do use "pci" device <damo22>but its abstracted via libpciaccess <damo22>what about the case where rumpdisk accesses pci before any arbiter, it becomes the master pci accessor? but then it would block further pci clients from getting access to pci because the arbiter does not get a chance to run as master <damo22>maybe we should enforce that only an arbiter can get first dibs on the io ports <damo22>or do we already do that with this code: <damo22> if (&netfs_server_name && netfs_server_name <damo22> && !strcmp(netfs_server_name, "pci-arbiter")) { <damo22>since it will only try to be a client unless the name is pci-arbiter <damo22>im looking forward to multicore hurd <damo22>i can run -smp 6 and still have plenty to spare on my laptop <damo22>make[1]: Leaving directory '/part3/debian/rumpkernel' <damo22> dh_install -a <HANG> with load 5.3 <damo22>something is deadlocked between rumpdisk and ext2fs <damo22> 7 root 3 -17 392852 261216 0 R 46.0 12.5 2:34.75 rumpdisk <damo22> 721 root 19 -1 687220 2500 0 R 41.4 0.1 6:41.87 ext2fs <damo22>[ 1.0200050] ahcisata0: AHCI revision 1.0, 6 ports, 32 slots, CAP 0xc0141f05<SAM,ISS=0x1=Gen1,SNCQ,S64A> <damo22>irq handler [1]: new delivery port f4e5c3e8 entry f4e30e40 ***Noisytoot_ is now known as Noisytoot
<Curiosa>damo22: would you put your acpi patches somewhere along with a couple of instructions on how to compile on Debian, so that we can test Hurd on an SMP enabled GnuMach? <Curiosa>Regarding the patches you posted on the mailing list, I wonder why you are renaming the api functions in the Hurd instead of keeping the names that ACPICA uses? <Zopolis4>does cmake have anything for handling hurd?