Re: em problem in virtualbox since the weekend
On Thursday, July 21, 2011 6:37:05 pm Jung-uk Kim wrote: On Thursday 21 July 2011 11:53 am, John Baldwin wrote: On Wednesday, July 20, 2011 6:22:33 pm Steve Wills wrote: On 07/20/11 09:04, John Baldwin wrote: On Wednesday, July 20, 2011 8:33:07 am Bernhard Froehlich wrote: On Wed, 20 Jul 2011 07:41:26 -0400, John Baldwin wrote: On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote: Hi, While testing some other things, I found -CURRENT from yesterday doesn't work with the em0 in my VirtualBox 4.0.8 (a little out of date admittedly). It worked Friday or Saturday I think. Anyone else seen this or should I open a PR? Has the code changed or am I perhaps misremembering dates? The error reported is: em0: Unable to allocate bus resource: memory em0: Allocation of PCI resources failed This is due to a bug in VirtualBox's BIOS implementation. Someone should file a bug report with VirtualBox to ask them to fix their BIOS. The problem is that they claim that the Host-PCI bridge in their system only decodes addresses 0xa-0xb (i.e. the VGA window) via the Producer resources in the _CRS method of the Host-PCI bridge device. This tells the OS that all the existing PCI devices are using invalid memory address ranges but that there is also no available address space to allocate for PCI devices such as em0. You can workaround this by setting debug.acpi.disabled=hostres until VirtualBox fixes their code. I'm happy to provide further clarification to an existing VirtaulBox bug report if needed. Thanks a lot for the analysis! I've talked to one of the virtualbox developers about that but they are not aware of such problems with Linux or Windows guests yet. So they are currently unsure if it's a VirtualBox or FreeBSD fault and if it's their fault why it works fine with other guests. I'm also unsure because I haven't heard of that problem before and now multiple people complain. That looks more like a FreeBSD related problem on current or stable. I think it would be good if someone could try to reproduce that with emulators/virtualbox-ose-legacy which is 3.2.12 to get some vbox dev look into the problem again. FreeBSD just started honoring this setting in the BIOS this week and ignored it previously. Can you get an acpidump from within VirtaulBox? I might be able to point to a bug in it directly if so. Thanks for the info! I've attached the acpidump and also posted a copy here: http://people.freebsd.org/~swills/vbox-4.0.8.asl.gz in case the mailing list eats it. Hmm, so there does look to be a reasonable _CRS method. Oh, I think I see what I don't like: DWordMemory (ResourceProducer, PosDecode, MinNotFixed, MaxFixed, Cacheable, ReadWrite, 0x, // Granularity 0x, // Range Minimum 0xFFDF, // Range Maximum 0x, // Translation Offset 0x, // Length ,, _Y01, AddressRangeMemory, TypeStatic) It should be using MinFixed, not MinNotFixed. Actually, I am responsible for this: http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/virtualbox- ose/files/Attic/patch-src-VBox-Devices-PC-vbox.dsl?rev=1.1;content- type=text%2Fplain I believe this patch was submitted upstream later. Author: jhb Date: Thu Jul 21 20:43:43 2011 New Revision: 224254 URL: http://svn.freebsd.org/changeset/base/224254 Log: Allow non-fixed endpoints for a producer address range if the length of the resource covers the entire range. Some BIOSes appear to mark endpoints as non-fixed incorrectly (non-fixed endpoints are supposed to be used in _PRS when OSPM is allowed to allocate a certain chunk of address space within a larger range, I don't believe it is supposed to be used for _CRS). No, _CRS can use MinNotFixed (and MaxNotFixed). You can find similar examples from ACPI spec. Err, this is clearly illegal. Consult Table 6-38 from ACPI Spec 3.0b (page 213, actual page 233 in the PDF). If the _LEN of an Address Space Descriptor is 0, then _MIF (Min Fixed) must equal _MAF (Max Fixed). Having one fixed and not the other is explicitly marked illegal. Furthermore, the case where _MIF == _MAF == 0 has this description: Fixed size, variable location resource descriptor for _PRS. _LEN must be a multiple of (_GRA + 1). OS can pick the resource range that satisfies following conditions: * Start address is a multiple of (_GRA + 1) and greater or equal to _MIN. * End address is (start_address + _LEN - 1) and less or equal to _MAX. That explicitly states that this is _only_ for _PRS. Thus, the only valid combination for _CRS for _MIF and _MAF with a length != 0
Re: em problem in virtualbox since the weekend
On Friday 22 July 2011 08:05 am, John Baldwin wrote: On Thursday, July 21, 2011 6:37:05 pm Jung-uk Kim wrote: On Thursday 21 July 2011 11:53 am, John Baldwin wrote: On Wednesday, July 20, 2011 6:22:33 pm Steve Wills wrote: On 07/20/11 09:04, John Baldwin wrote: On Wednesday, July 20, 2011 8:33:07 am Bernhard Froehlich wrote: On Wed, 20 Jul 2011 07:41:26 -0400, John Baldwin wrote: On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote: Hi, While testing some other things, I found -CURRENT from yesterday doesn't work with the em0 in my VirtualBox 4.0.8 (a little out of date admittedly). It worked Friday or Saturday I think. Anyone else seen this or should I open a PR? Has the code changed or am I perhaps misremembering dates? The error reported is: em0: Unable to allocate bus resource: memory em0: Allocation of PCI resources failed This is due to a bug in VirtualBox's BIOS implementation. Someone should file a bug report with VirtualBox to ask them to fix their BIOS. The problem is that they claim that the Host-PCI bridge in their system only decodes addresses 0xa-0xb (i.e. the VGA window) via the Producer resources in the _CRS method of the Host-PCI bridge device. This tells the OS that all the existing PCI devices are using invalid memory address ranges but that there is also no available address space to allocate for PCI devices such as em0. You can workaround this by setting debug.acpi.disabled=hostres until VirtualBox fixes their code. I'm happy to provide further clarification to an existing VirtaulBox bug report if needed. Thanks a lot for the analysis! I've talked to one of the virtualbox developers about that but they are not aware of such problems with Linux or Windows guests yet. So they are currently unsure if it's a VirtualBox or FreeBSD fault and if it's their fault why it works fine with other guests. I'm also unsure because I haven't heard of that problem before and now multiple people complain. That looks more like a FreeBSD related problem on current or stable. I think it would be good if someone could try to reproduce that with emulators/virtualbox-ose-legacy which is 3.2.12 to get some vbox dev look into the problem again. FreeBSD just started honoring this setting in the BIOS this week and ignored it previously. Can you get an acpidump from within VirtaulBox? I might be able to point to a bug in it directly if so. Thanks for the info! I've attached the acpidump and also posted a copy here: http://people.freebsd.org/~swills/vbox-4.0.8.asl.gz in case the mailing list eats it. Hmm, so there does look to be a reasonable _CRS method. Oh, I think I see what I don't like: DWordMemory (ResourceProducer, PosDecode, MinNotFixed, MaxFixed, Cacheable, ReadWrite, 0x, // Granularity 0x, // Range Minimum 0xFFDF, // Range Maximum 0x, // Translation Offset 0x, // Length ,, _Y01, AddressRangeMemory, TypeStatic) It should be using MinFixed, not MinNotFixed. Actually, I am responsible for this: http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/virtualbox- ose/files/Attic/patch-src-VBox-Devices-PC-vbox.dsl?rev=1.1;content- type=text%2Fplain I believe this patch was submitted upstream later. Author: jhb Date: Thu Jul 21 20:43:43 2011 New Revision: 224254 URL: http://svn.freebsd.org/changeset/base/224254 Log: Allow non-fixed endpoints for a producer address range if the length of the resource covers the entire range. Some BIOSes appear to mark endpoints as non-fixed incorrectly (non-fixed endpoints are supposed to be used in _PRS when OSPM is allowed to allocate a certain chunk of address space within a larger range, I don't believe it is supposed to be used for _CRS). No, _CRS can use MinNotFixed (and MaxNotFixed). You can find similar examples from ACPI spec. Err, this is clearly illegal. Consult Table 6-38 from ACPI Spec 3.0b (page 213, actual page 233 in the PDF). If the _LEN of an Address Space Descriptor is 0, then _MIF (Min Fixed) must equal _MAF (Max Fixed). Having one fixed and not the other is explicitly marked illegal. Furthermore, the case where _MIF == _MAF == 0 has this description: Fixed size, variable location resource descriptor for _PRS. _LEN must be a multiple of (_GRA + 1). OS can pick the resource range that satisfies following conditions: * Start address is a multiple of (_GRA + 1) and greater or equal to _MIN. * End address is (start_address + _LEN - 1) and
Re: [patch] Intel SATA controller hiccups, locking
Andrew Boyer wrote: Thank you for looking into it! I would really like to get Alexander's feedback before it gets committed. Improved version committed at r224270. On Jul 20, 2011, at 4:18 PM, Vogel, Jack wrote: Ran it by the chipset contact internally and he said go for it, you need me to check it in Andrew? -Original Message- From: Andrew Boyer [mailto:abo...@averesystems.com] Sent: Wednesday, July 20, 2011 7:45 AM To: m...@freebsd.org Cc: freebsd-current@freebsd.org; Vogel, Jack Subject: [patch] Intel SATA controller hiccups, locking Hello Alexander, I am using the latest ata driver from stable/8 on a system with an Intel ICH10 controller. ATA_CAM and ATA_STATIC_ID are both off. There is one drive connected to port 3. SATA is set to Enhanced / IDE mode (not AHCI) in the BIOS. atapci0@pci0:0:31:2:class=0x01018f card=0x060d15d9 chip=0x3a208086 rev=0x00 hdr=0x00 atapci1@pci0:0:31:5:class=0x010185 card=0x060d15d9 chip=0x3a268086 rev=0x00 hdr=0x00 atapci0: Intel ICH10 SATA300 controller port 0xbff0-0xbff7,0xbf7c-0xbf7f,0xbfe0-0xbfe7,0xbef4-0xbef7,0xbfa0-0xbfaf,0xbf60-0xbf6f irq 19 at device 31.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbfa0 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: Reserved 0x10 bytes for rid 0x24 type 4 at 0xbf60 ata2: ATA channel 0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xbff0 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbf7c ata2: SATA reset: ports status=0x00 ata2: p0: SATA connect timeout status= ata2: p1: SATA connect timeout status= ata2: [MPSAFE] ata2: [ITHREAD] ata3: ATA channel 1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xbfe0 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xbef4 ata3: SATA reset: ports status=0x08 ata3: p0: SATA connect timeout status= ata3: p1: SATA connect time=0ms status=0123 ata3: reset tp1 mask=03 ostat0=7f ostat1=50 ata3: stat0=0x7f err=0x00 lsb=0xff msb=0xff ata3: stat1=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=7f stat1=50 devices=0x2 ata3: [MPSAFE] ata3: [ITHREAD] When under heavy load, the 'atacontrol mode ad0' command sometimes fails to determine the SATA speed; the drive appears to be missing. I think the root cause is that chipsets/ata-intel.c does not do any locking on the ata_intel_sata_sidpr_* routines. The (write address register) + (access data register) model isn't safe without locking because two channels share the registers. The ata_intel_sata_cscr_* routines have the same problem. Adding a mutex to a structure stored in ctlr-chipset_data makes the hiccups go away; see the attached patch. Please advise if this is something you would like to fix. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: em problem in virtualbox since the weekend
On Friday, July 22, 2011 12:19:24 pm Jung-uk Kim wrote: On Friday 22 July 2011 08:05 am, John Baldwin wrote: Err, this is clearly illegal. Consult Table 6-38 from ACPI Spec 3.0b (page 213, actual page 233 in the PDF). If the _LEN of an Address Space Descriptor is 0, then _MIF (Min Fixed) must equal _MAF (Max Fixed). Having one fixed and not the other is explicitly marked illegal. Furthermore, the case where _MIF == _MAF == 0 has this description: Fixed size, variable location resource descriptor for _PRS. _LEN must be a multiple of (_GRA + 1). OS can pick the resource range that satisfies following conditions: * Start address is a multiple of (_GRA + 1) and greater or equal to _MIN. * End address is (start_address + _LEN - 1) and less or equal to _MAX. That explicitly states that this is _only_ for _PRS. Thus, the only valid combination for _CRS for _MIF and _MAF with a length != 0 is to have both endpoints fixed. Further, note that for the case were _LEN is zero, all valid cases are described by a block starting thus: Variable size, variable location resource descriptor for _PRS. Given this, the _only_ valid combination for _CRS is Length != 0, and _MIF == _MAF == 1. All other resources in _CRS are illegal. I was sure that my patch is okay because I found an example in the 4.0a page 356 had a _CRS example where _MIF == _MAF == _LEN == 0. So, I thought it wasn't strictly for _PRS. I'll ask Intel guys for clarification. Hmm, that does seem to contradict the earlier section. I wonder if that example is just broken? It is supposed to be an example talking about assigning PCI bus numbers. Note that both of those examples do use a length of 0, so perhaps they are expecting the OS to ignore them? BTW, this same table is reproduced verbatim in 4.0a (now table 6-40 on page 260). Hmm... Maybe I mis-interpreted the table somehow. Note the original code was _MIF == _MAF == 1, and _LEN 0 but _LEN != (_MAX - _MIN) + 1: -- DwordMemory( // Consumed-and-produced resource // (all of low memory space) ResourceProducer,// bit 0 of general flags is 0 PosDecode, // positive Decode MinFixed,// Range is not fixed MaxFixed,// Range is fixed Cacheable, ReadWrite, 0x, // Granularity 0x, // Min (calculated dynamically) 0xffdf, // Max = 4GB - 2MB 0x, // Translation 0xdfdf, // Range Length (calculated // dynamically) ,// Optional field left blank ,// Optional field left blank MEM3 // Name declaration for this // descriptor ) -- Intel ACPI Component Architecture ASL Optimizing Compiler version 20110527-64 Copyright (c) 2000 - 2011 Intel Corporation vbox.dsl 1103: 0xdfdf, // Range Length (calculated Error4118 -^ Length is not equal to fixed Min/Max window ASL Input: vbox.dsl - 1425 lines, 52542 bytes, 338 keywords Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 416 Optimizations -- Both _MIN and _LEN are dynamically calculated, so I guess the simplest fix should have been: --- vbox.dsl.orig 2011-07-22 12:01:33.0 -0400 +++ vbox.dsl2011-07-22 12:03:41.0 -0400 @@ -1100,7 +1100,7 @@ 0xffdf, // Max = 4GB - 2MB 0x, // Translation - 0xdfdf, // Range Length (calculated + 0xffe0, // Range Length (calculated // dynamically) ,// Optional field left blank ,// Optional field left blank This should have satisfied the table without breaking too much. :-( Well, perhaps the best fix would be to set the length to 0 instead. Maybe the compiler is possibly broken here. The Fixed vs NotFixed matters in terms of what is actually presented to the OS once the _CRS method has run, not how _CRS may choose to populate the buffers. _CRS may dynamically calculate what the _MAX and _LEN fields are (this is very common), but the finished buffer that the OS sees is for a fixed resource range, so it should use Fixed for both endpoints. So for example, this is what I see on a test system here for the main PCI memory window region: DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x, // Granularity 0x,
Re: em problem in virtualbox since the weekend
On Friday 22 July 2011 01:41 pm, John Baldwin wrote: On Friday, July 22, 2011 12:19:24 pm Jung-uk Kim wrote: On Friday 22 July 2011 08:05 am, John Baldwin wrote: Err, this is clearly illegal. Consult Table 6-38 from ACPI Spec 3.0b (page 213, actual page 233 in the PDF). If the _LEN of an Address Space Descriptor is 0, then _MIF (Min Fixed) must equal _MAF (Max Fixed). Having one fixed and not the other is explicitly marked illegal. Furthermore, the case where _MIF == _MAF == 0 has this description: Fixed size, variable location resource descriptor for _PRS. _LEN must be a multiple of (_GRA + 1). OS can pick the resource range that satisfies following conditions: * Start address is a multiple of (_GRA + 1) and greater or equal to _MIN. * End address is (start_address + _LEN - 1) and less or equal to _MAX. That explicitly states that this is _only_ for _PRS. Thus, the only valid combination for _CRS for _MIF and _MAF with a length != 0 is to have both endpoints fixed. Further, note that for the case were _LEN is zero, all valid cases are described by a block starting thus: Variable size, variable location resource descriptor for _PRS. Given this, the _only_ valid combination for _CRS is Length != 0, and _MIF == _MAF == 1. All other resources in _CRS are illegal. I was sure that my patch is okay because I found an example in the 4.0a page 356 had a _CRS example where _MIF == _MAF == _LEN == 0. So, I thought it wasn't strictly for _PRS. I'll ask Intel guys for clarification. Hmm, that does seem to contradict the earlier section. I wonder if that example is just broken? It is supposed to be an example talking about assigning PCI bus numbers. Note that both of those examples do use a length of 0, so perhaps they are expecting the OS to ignore them? Now I think the example is broken. However, a lot of BIOS writers just copy and paste examples from the spec. without looking closely. In fact, I've seen many such cases. :-( BTW, this same table is reproduced verbatim in 4.0a (now table 6-40 on page 260). Hmm... Maybe I mis-interpreted the table somehow. Note the original code was _MIF == _MAF == 1, and _LEN 0 but _LEN != (_MAX - _MIN) + 1: -- DwordMemory( // Consumed-and-produced resource // (all of low memory space) ResourceProducer,// bit 0 of general flags is 0 PosDecode, // positive Decode MinFixed,// Range is not fixed MaxFixed,// Range is fixed Cacheable, ReadWrite, 0x, // Granularity 0x, // Min (calculated dynamically) 0xffdf, // Max = 4GB - 2MB 0x, // Translation 0xdfdf, // Range Length (calculated // dynamically) ,// Optional field left blank ,// Optional field left blank MEM3 // Name declaration for this // descriptor ) -- Intel ACPI Component Architecture ASL Optimizing Compiler version 20110527-64 Copyright (c) 2000 - 2011 Intel Corporation vbox.dsl 1103: 0xdfdf, // Range Length (calculated Error4118 - ^ Length is not equal to fixed Min/Max window ASL Input: vbox.dsl - 1425 lines, 52542 bytes, 338 keywords Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 416 Optimizations -- Both _MIN and _LEN are dynamically calculated, so I guess the simplest fix should have been: --- vbox.dsl.orig 2011-07-22 12:01:33.0 -0400 +++ vbox.dsl2011-07-22 12:03:41.0 -0400 @@ -1100,7 +1100,7 @@ 0xffdf, // Max = 4GB - 2MB 0x, // Translation - 0xdfdf, // Range Length (calculated + 0xffe0, // Range Length (calculated // dynamically) , // Optional field left blank ,// Optional field left blank This should have satisfied the table without breaking too much. :-( Well, perhaps the best fix would be to set the length to 0 instead. Maybe the compiler is possibly broken here. The Fixed vs NotFixed matters in terms of what is actually presented to the OS once the _CRS method has run, not how _CRS may choose to populate the buffers. _CRS may dynamically calculate what the _MAX and _LEN fields are (this is very common), but the finished buffer that the OS sees is for a fixed resource range, so it should use Fixed for both endpoints. So for example, this is what I see on a test system
Re: em problem in virtualbox since the weekend
On 07/21/11 15:10, Scot Hetzel wrote: On Thu, Jul 21, 2011 at 10:53 AM, John Baldwin j...@freebsd.org wrote: Hmm, so there does look to be a reasonable _CRS method. Oh, I think I see what I don't like: DWordMemory (ResourceProducer, PosDecode, MinNotFixed, MaxFixed, Cacheable, ReadWrite, 0x, // Granularity 0x, // Range Minimum 0xFFDF, // Range Maximum 0x, // Translation Offset 0x, // Length ,, _Y01, AddressRangeMemory, TypeStatic) This patch fixed the problem with my recent install of FreeBSD 9.0 on VirtualBox. Thanks for the fix. Same here, thanks! Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
