Could not map memory
Hello Actually I've noticed problem because all my usb devices aren't work. I've googled that problem, but didn't find any good solution. I found that all works well in linux and windows, but not at FreeBSD. Now I have FreeBSD 8.1 So, after booting with verbose, I have: *dmesg* ohci0: ATI SB400 USB Controller mem 0x8000-0x8fff irq 19 at device 19.0 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 51 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: ATI SB400 USB Controller on ohci0 ohci1: ATI SB400 USB Controller mem 0x8000-0x8fff irq 19 at device 19.1 on pci0 ohci1: Could not map memory device_attach: ohci1 attach returned 6 ehci0: ATI SB400 USB 2.0 controller mem 0x8000-0x8fff irq 19 at device 19.2 on pci0 ehci0: Could not map memory device_attach: ehci0 attach returned 6 ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: MacBookPro 5,1
On Tue, 2010-10-19 at 04:21 +0800, Hans Petter Selasky wrote: On Monday 18 October 2010 02:01:09 Moore, Robert wrote: Can you send us the acpidump for the machine? Also, tell us which control method is failing. Thanks Hi, Please find attached dump of ACPI tables. It is the function AcpiRsCreateAmlResources() which writes beyond the buffer it allocates. Could you enable AML debug output to get more info? But I don't know how to enable it on FreeBSD. In Linux, the AML debug output is enabled with kernel boot parameters like below. acpi.debug_layer=0x acpi.debug_level=0x FreeBSD may have some similar boot parameters. Lin Ming --HPS ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: Could not map memory
On Tue, 19 Oct 2010, rufina sarvarova wrote: Date: Tue, 19 Oct 2010 09:39:44 +0400 From: rufina sarvarova rufina.sarvar...@gmail.com To: freebsd-acpi@freebsd.org Subject: Could not map memory Hello I can't help with your problem, but you posted this same message SEVEN times in a row to this list, all with the same original date/time. 4172 Oct 19 rufina sarvarova (4323) Could not map memory 4173 Oct 19 rufina sarvarova (4323) Could not map memory 4174 Oct 19 rufina sarvarova (4323) Could not map memory 4175 Oct 19 rufina sarvarova (4341) Could not map memory 4176 Oct 19 rufina sarvarova (4341) Could not map memory 4177 Oct 19 rufina sarvarova (4323) Could not map memory 4178 Oct 19 rufina sarvarova (4323) Could not map memory Please check and fix your gmail setup to avoid this happening again. cheers, Ian ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: VirtualBox: Compile problems with ACPICA 20101013
On Mon, 18 Oct 2010 13:33:26 -0400, Jung-uk Kim j...@freebsd.org wrote: On Monday 18 October 2010 05:44 am, Bernhard Froehlich wrote: Hi guys! VirtualBox has a compile problem with latest acpica. I've talked to the VirtualBox developers and they think it's an acpica problem which should be fixed upstream. Can we somehow file a bugreport or create a patch to fix that in acpica? Excerpt rom ACPI 4.0a: --- Each Compatible Device ID must be either: o A valid HID value (a 32-bit compressed EISA type ID or a string such as ACPI0004). o A string that uses a bus-specific nomenclature. For example, _CID can be used to specify the PCI ID. --- Since it is not a valid HID value, you can only say it may be a bus-specific nomenclature at best. However, it looks like an ISA device to me and probably it is just a bogus ID. In fact, I googled a bit and it only exists on some Intel Mac models, it seems. You can just remove the entire _CID unless it is absolutely necessary, which is very unlikely. :-) It very much looks like a regression. Right beyond that sentences they have a few examples in the ACPI 4.0a spec on page 201 that won't pass that check. I haven't looked at all the code so probably it's done somewhere completely different but if it is checked with that code then it will complain. ACPI 4.0a spec on page 201: --- o A valid HID value (a 32-bit compressed EISA type ID or a string such as ACPI0004). o A string that uses a bus-specific nomenclature. For example, _CID can be used to specify the PCI ID. PCI\CC_ccss PCI\CC_ccsspp PCI\VEN_DEV_SUBSYS_REV_rr --- Now with a deeper look at the commit from acpica [1] especially the second half. Before there was only an alphanumeric check for _HID but with that change it was put into a new function AnCheckId() that is called for both _HID and _CID and now wants both to be alphanumeric. That looks correct for _HID but it's too strict for _CID which is a string. Somewhere i've seen string is defined as a null-terminated ASCII string and no word about alphanumeric. [1] http://git.moblin.org/cgit.cgi/acpica/commit/?id=b66fd716e0b9b5389e Compile error: kBuild: iasl DevicesR3 - /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.2.10_OSE/src/ VBox/Devices/PC/vbox.dsl /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.2.10_OSE/src/ VBox/Devices/PC/vbox.dsl 736: Name (_CID, smc-napa) Error4001 - String must be entirely alphanumeric ^ (smc-napa) ASL Input: /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.2.10_OSE/src/ VBox/Devices/PC/vbox.dsl - 1305 lines, 46193 bytes, 288 keywords Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 404 Optimizations I have found the commit that introduces this additional checks: http://git.moblin.org/cgit.cgi/acpica/commit/?id=b66fd716e0b9b5389e 544c58df189c817f316c3b and here is the dsl file from virtualbox: http://www.virtualbox.org/browser/trunk/src/VBox/Devices/PC/vbox.ds l#L781 Thanks! -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: VirtualBox: Compile problems with ACPICA 20101013
On Tuesday 19 October 2010 08:52 am, Bernhard Froehlich wrote: On Mon, 18 Oct 2010 13:33:26 -0400, Jung-uk Kim j...@freebsd.org wrote: On Monday 18 October 2010 05:44 am, Bernhard Froehlich wrote: Hi guys! VirtualBox has a compile problem with latest acpica. I've talked to the VirtualBox developers and they think it's an acpica problem which should be fixed upstream. Can we somehow file a bugreport or create a patch to fix that in acpica? Excerpt rom ACPI 4.0a: --- Each Compatible Device ID must be either: o A valid HID value (a 32-bit compressed EISA type ID or a string such as ACPI0004). o A string that uses a bus-specific nomenclature. For example, _CID can be used to specify the PCI ID. --- Since it is not a valid HID value, you can only say it may be a bus-specific nomenclature at best. However, it looks like an ISA device to me and probably it is just a bogus ID. In fact, I googled a bit and it only exists on some Intel Mac models, it seems. You can just remove the entire _CID unless it is absolutely necessary, which is very unlikely. :-) It very much looks like a regression. Right beyond that sentences they have a few examples in the ACPI 4.0a spec on page 201 that won't pass that check. I haven't looked at all the code so probably it's done somewhere completely different but if it is checked with that code then it will complain. ACPI 4.0a spec on page 201: --- o A valid HID value (a 32-bit compressed EISA type ID or a string such as ACPI0004). o A string that uses a bus-specific nomenclature. For example, _CID can be used to specify the PCI ID. PCI\CC_ccss PCI\CC_ccsspp PCI\VEN_DEV_SUBSYS_REV_rr --- Now with a deeper look at the commit from acpica [1] especially the second half. Before there was only an alphanumeric check for _HID but with that change it was put into a new function AnCheckId() that is called for both _HID and _CID and now wants both to be alphanumeric. That looks correct for _HID but it's too strict for _CID which is a string. Somewhere i've seen string is defined as a null-terminated ASCII string and no word about alphanumeric. [1] http://git.moblin.org/cgit.cgi/acpica/commit/?id=b66fd716e0b9b5389e Yes, I am aware of the issue. My point was _CID may be pointless for *VirtualBox* and it can be removed. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: Could not map memory
[restored mailing list cc] on 19/10/2010 19:33 rufina sarvarova said the following: found- vendor=0x1002, dev=0x4374, revid=0x80 domain=0, bus=0, slot=19, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 MSI supports 1 message map[10]: type Memory, range 32, base 0, size 12, memory disabled ^^ pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 19 unknown: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x8000 unknown: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x8000 found- vendor=0x1002, dev=0x4375, revid=0x80 domain=0, bus=0, slot=19, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type Memory, range 32, base 0, size 12, memory disabled ^^ pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 19 unknown: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x8000 unknown: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x8000 found- vendor=0x1002, dev=0x4373, revid=0x80 domain=0, bus=0, slot=19, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message map[10]: type Memory, range 32, base 0, size 12, memory disabled ^^ pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 19 unknown: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x8000 unknown: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x8000 ehci early: SMM active, request owner change ehci early: SMM does not respond I think that the problem is in underlined lines. Your BIOS hasn't configured BARs for USB devices for some reason and unfortunately FreeBSD wasn't smart enough to do it correctly without assistance from BIOS. -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
