Re: FreeBSD 9.0 CURRENT: /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: error: use of undeclared identifier 'vap'
No problem,
I just mentioned it to make people aware ...
Oliver
On 07/20/11 02:48, Adrian Chadd wrote:
just committed that.
Sorry, I thought that version of the patch had compiled right. Sorry ;(
adrian
2011/7/20 fidajfi...@ukr.net:
--- Оригінальне повідомлення ---
Від кого: Hartmann, O.ohart...@zedat.fu-berlin.de
Кому: FreeBSD Currentfreebsd-current@freebsd.org
Дата: 19 липня 2011, 22:00:20
Тема: Re: FreeBSD 9.0 CURRENT:
/usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16:
error: use of undeclared identifier 'vap'
FreeBSD 9.0-CURRENT/amd64 stopps building kernel with the following
error in module wlan:
clang -O3 -mtune=native -fno-strict-aliasing -pipe -march=native
-D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq
-fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR
-mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c
/usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c
/usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16:
error: use of undeclared identifier 'vap'
TAILQ_FOREACH(vap,ic-ic_vaps, iv_next)
^
@/sys/queue.h:521:8: note: expanded from:
for ((var) = TAILQ_FIRST((head)); \
^
/usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16:
error: use of undeclared identifier 'vap'
TAILQ_FOREACH(vap,ic-ic_vaps, iv_next)
^
@/sys/queue.h:522:7: note: expanded from:
(var); \
^
/usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16:
error: use of undeclared identifier 'vap'
TAILQ_FOREACH(vap,ic-ic_vaps, iv_next)
^
@/sys/queue.h:523:7: note: expanded from:
(var) = TAILQ_NEXT((var), field))
^
/usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16:
error: use of undeclared identifier 'vap'
TAILQ_FOREACH(vap,ic-ic_vaps, iv_next)
^
@/sys/queue.h:523:26: note: expanded from:
(var) = TAILQ_NEXT((var), field))
^
@/sys/queue.h:597:34: note: expanded from:
#define TAILQ_NEXT(elm, field) ((elm)-field.tqe_next)
^
/usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1542:7:
error: use of undeclared identifier 'vap'
if (vap-iv_state == IEEE80211_S_CSA)
^
/usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1543:4:
error: use of undeclared identifier 'vap'
vap-iv_bss-ni_chan = ic-ic_curchan;
^
6 errors generated.
*** Error code 1
Stop in /usr/src/sys/modules/wlan.
Regards,
Oliver
___ 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
--- ieee80211_proto.c.orig2011-07-20 01:06:17.0 +0300
+++ ieee80211_proto.c2011-07-20 01:10:54.0 +0300
@@ -1533,6 +1533,8 @@
void
ieee80211_csa_completeswitch(struct ieee80211com *ic)
{
+struct ieee80211vap *vap;
+
IEEE80211_LOCK_ASSERT(ic);
KASSERT(ic-ic_flags IEEE80211_F_CSAPENDING, (csa not pending));
___
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
___
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
___
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 7/20/2011 5:35 AM, Steve Wills wrote: 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 I also see this on a 4.0.4something installation. em0: Unable to allocate bus resource: memory em0: Allocation of PCI resources failed So, you're not alone:) Nikos ___ 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 Wed, Jul 20, 2011 at 10:59 AM, Nikos Vassiliadis nv...@gmx.com wrote: On 7/20/2011 5:35 AM, Steve Wills wrote: 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 I also see this on a 4.0.4something installation. em0: Unable to allocate bus resource: memory em0: Allocation of PCI resources failed So, you're not alone:) Nikos Same here. I've tried all possible NIC emulations to no avail. -- Good, fast cheap. Pick any two. ___ 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 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. -- John Baldwin ___ 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 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. -- Bernhard Froehlich http://www.bluelife.at/ ___ 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 2011-07-20 14:33, 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. This may or may not be related, apologies if it is not. My FreeBSD VirtualBox guest, running inside vbox under Windows, is having trouble mounting it's root partition, mountroot dies with error 19 (which is ENODEV, I've come to understand). I can also see in the dmesg prior to this ahci, ehci and ohci not being able to allocate resources properly, or something similar. Rebuilding the kernel with nooptions NEW_PCIB solves the immediate issue (i.e. the machine boots and can find filesystems, etc.). It is probably so, that if there is a bug in vbox bios, the old pci code masks that bug, but the new version is more stringent and therefore dies on it. This can be the reason no one has seen this issue up until now. Why it works for Linux and Windows guests, I have no idea. I hope this helps someone, or at least can shed some light on the issue at hand. Regards! -- Niclas Zeising ___ 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
[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. Thank you, Andrew ata_intel_sata.diff Description: Binary data -- Andrew Boyerabo...@averesystems.com ___ 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 Wednesday, July 20, 2011 10:33:19 am Niclas Zeising wrote: On 2011-07-20 14:33, 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. This may or may not be related, apologies if it is not. My FreeBSD VirtualBox guest, running inside vbox under Windows, is having trouble mounting it's root partition, mountroot dies with error 19 (which is ENODEV, I've come to understand). I can also see in the dmesg prior to this ahci, ehci and ohci not being able to allocate resources properly, or something similar. Rebuilding the kernel with nooptions NEW_PCIB solves the immediate issue (i.e. the machine boots and can find filesystems, etc.). It is probably so, that if there is a bug in vbox bios, the old pci code masks that bug, but the new version is more stringent and therefore dies on it. This can be the reason no one has seen this issue up until now. Why it works for Linux and Windows guests, I have no idea. I hope this helps someone, or at least can shed some light on the issue at hand. Yes, that is the same bug. The old PCI code is less stringent (but also less functional in other cases as a result). -- John Baldwin ___ 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[2]: AX88772A AX88772B chipset differences?
13 июля 2011, 04:07 от YongHyeon PYUN pyu...@gmail.com: On Thu, Jun 30, 2011 at 10:19:14AM -0700, YongHyeon PYUN wrote: On Thu, Jun 30, 2011 at 02:44:48PM +0400, Andrey Smagin wrote: I have card based on AX88772B. I tried patch axe driver for vendor and device IDs. card detected, set up link, but no data received. What else need for patch in this driver ? Anybody have datasheet ? ASIX requires a login account to get the data sheet so it's not publicly available to open source developers. AFAIK the difference between AX88772A and AX88772B is IPv4/IPv6 checksum offloading support of AX88772B. The introduction of checksum offloading means they might have changed its RX header format which in turn makes current RX handler to not work. The other difference would be more advanced power saving used in AX8877B but it wouldn't be much difference to axe(4) driver once PHY is correctly woken in initialization phase. Could you show me your diff and verbose boot output to know PHY model and EEPROM data? I have a minimal patch for AX88772B. It requires more work to support TX/RX checksum offloading, flow-control and power saving but attached patch would be enough for most cases. Let me know whether it works or not. Great thanx !!! It work but I not tested under heavy load. Only ping and some Mbytes via nfs. ___ 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
pcib1: failed to allocate initial memory window
Hi all, Built a fresh kernel today (-CURRENT) on my DELL workstation (amd64). The network card does not get detected. Booted the old kernel again. Are there any chances to get this fixed or is this a candidate for a buggy BIOS? Attached the devinfo -r from the running kernel. Also the acpidump -dt. Any help would be appreciated. TIA, Andreas kernel: pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 kernel: pcib1: failed to allocate initial memory window: 0xe800-0xefef kernel: pcib1: failed to allocate initial prefetch window: 0xd800-0xdfff kernel: pci1: ACPI PCI bus on pcib1 kernel: vgapci0: VGA-compatible display irq 16 at device 0.0 on pci1 kernel: hdac0: Intel 82801G High Definition Audio Controller irq 16 at device 27.0 on pci0 kernel: pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 kernel: pcib2: failed to allocate initial memory window: 0xe7f0-0xe7ff kernel: pci2: ACPI PCI bus on pcib2 kernel: pcib3: ACPI PCI-PCI bridge irq 16 at device 28.4 on pci0 kernel: pci3: ACPI PCI bus on pcib3 kernel: pcib4: ACPI PCI-PCI bridge irq 17 at device 28.5 on pci0 kernel: pcib4: failed to allocate initial memory window: 0xe7e0-0xe7ef kernel: pci4: ACPI PCI bus on pcib4 kernel: bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x00b002 irq 17 at device 0.0 on pci4 kernel: bge0: 0x1 bytes of rid 0x10 res 3 failed (0, 0x). kernel: bge0: couldn't map memory kernel: device_attach: bge0 attach returned 6 ___ 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: AX88772A AX88772B chipset differences?
On Wed, Jul 20, 2011 at 11:46:54PM +0400, Andrey Smagin wrote: 13 июля 2011, 04:07 от YongHyeon PYUN pyu...@gmail.com: On Thu, Jun 30, 2011 at 10:19:14AM -0700, YongHyeon PYUN wrote: On Thu, Jun 30, 2011 at 02:44:48PM +0400, Andrey Smagin wrote: I have card based on AX88772B. I tried patch axe driver for vendor and device IDs. card detected, set up link, but no data received. What else need for patch in this driver ? Anybody have datasheet ? ASIX requires a login account to get the data sheet so it's not publicly available to open source developers. AFAIK the difference between AX88772A and AX88772B is IPv4/IPv6 checksum offloading support of AX88772B. The introduction of checksum offloading means they might have changed its RX header format which in turn makes current RX handler to not work. The other difference would be more advanced power saving used in AX8877B but it wouldn't be much difference to axe(4) driver once PHY is correctly woken in initialization phase. Could you show me your diff and verbose boot output to know PHY model and EEPROM data? I have a minimal patch for AX88772B. It requires more work to support TX/RX checksum offloading, flow-control and power saving but attached patch would be enough for most cases. Let me know whether it works or not. Great thanx !!! It work but I not tested under heavy load. Only ping and some Mbytes via nfs. Thanks for testing. The patch was already committed to HEAD(r224020). I'm implementing TX/RX checksum offloading and flow-control and that feature would be available in near future. Thanks. ___ 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: pcib1: failed to allocate initial memory window
On 20.07.11 22:25, Andreas Tobler wrote: Hi all, Built a fresh kernel today (-CURRENT) on my DELL workstation (amd64). The network card does not get detected. Booted the old kernel again. Are there any chances to get this fixed or is this a candidate for a buggy BIOS? Attached the devinfo -r from the running kernel. Also the acpidump -dt. They got eaten Here they are: http://people.freebsd.org/~andreast/acpidump_optiplex.txt http://people.freebsd.org/~andreast/devinfo_optiplex.txt Thanks, Andreas ___ 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: [patch] Intel SATA controller hiccups, locking
Thank you for looking into it! I would really like to get Alexander's feedback before it gets committed. -Andrew 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? Jack -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. Thank you, Andrew -- Andrew Boyerabo...@averesystems.com ___ 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: [patch] Intel SATA controller hiccups, locking
On 20.07.2011 23:36, Andrew Boyer wrote: Thank you for looking into it! I would really like to get Alexander's feedback before it gets committed. Generally it looks good, but I would tune few minor places. I'll look on it closer tomorrow. Thank you. 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOJ1UoAAoJEPXPYrMgexuhhngIAJ/gyw1DMCciYDOw2Ek53dCb Cx2zFFm32THagLFIewKSL7RDKr6fNcNWuAdfFm/zpKq8nGUjA16p9A4eoOvdVc5u MhAu7oPZlnx9pX1o/JRjW0mtWglrHvKMapsptzlGOmS8PZMQz9s+L+IvGhsY8+qV avQ0V/w/AwG+T7x/vaCPpPdDPubuxT7vO+A5x9r4aUtFbKWIzF/1rsbq3cjIiGXw ExMpcdDBGRyLsPpB4fzhjb/drOQMJAkO2PnPPkWDociWCnC8Da/qCr6keD1lZPtD wx0UnMd/pyzJKVAuf4+VcifABIJIZeRqStIH7CB1fOKhcT+HDwatbKrEFGSvEMs= =COvj -END PGP SIGNATURE- vbox-4.0.8.asl.gz.sig Description: Binary data ___ 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 Wed, Jul 20, 2011 at 8:33 AM, Bernhard Froehlich de...@freebsd.org wrote: 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. I saw the problem this weekend on a Linux host running virtualbox 3.2.8. I can ___ 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
