From jason.harmening at gmail.com Sun Jun 8 05:07:24 2008 From: jason.harmening at gmail.com (Jason Harmening) Date: Sun Jun 8 05:07:28 2008 Subject: bus_dmamem_alloc Message-ID: <200806072341.17041.jason.harmening@gmail.com> Hello, I've written a FreeBSD driver for Conexant CX2388x-based PCI TV capture cards. Of course the driver uses busdma to be as machine-independent as possible. One problem I've encountered is that bus_dmamem_alloc is inadequate for my needs. The CX2388x only understands 32-bit physical addreses, and the driver has two separate use cases for busdma: 1) Data buffers: These buffers may be relatively large (a 640x480 RGB32 video frame is ~1.2M), and therefore it is desirable that these buffers not be physically contiguous. 2) DMA program buffers: The DMA engine on the CX2388x is controlled by special-purpose RISC instructions, usually stored in host memory, that provide information on, among other things, the physical layout of the data buffers, which enables handling of non-contiguous data buffers. These programs are rarely more than a few pages in size, so for the sake of simplicity it is desirable that DMA program buffers be physically contiguous. For case 1), I malloc(9) the buffers and then feed them to busdma, since on most machines bus_dmamem_alloc just calls contigmalloc. Use of malloc(9) is suboptimal as it may result in bounce buffering for non-IOMMU machines with large amounts of RAM. For case 2), I contigmalloc the DMA program buffers in the 32-bit physical address range and then feed them to busdma. I don't use bus_dmamem_alloc here because it always allocates the maximum size specified in the bus_dma_tag_t. Since the driver supports dynamic data buffer allocation and DMA program generation, DMA program sizes may vary significantly. I therefore just create the bus_dma_tag_t with the maximum possible size for a DMA program buffer since I'd prefer not to have to re-create the tag every time the DMA program size changes. But always allocating the maximum buffer size would be a huge waste of contiguous memory, so bus_dmamem_alloc is out of the question here too. At the same time, use of contigmalloc is suboptimal as it may not be necessary to restrict the allocation to 32-bit physical addresses on IOMMU-equipped machines. This is something that bus_dmamem_alloc could take care of, if only it supported a size parameter (as I believe the NetBSD version does). So I have 3 questions: 1) Would it be possible to provide a bus_dmamem_alloc overload that takes a size parameter? We could call it bus_dmamem_alloc_size and have bus_dmamem_alloc just call bus_dmamem_alloc_size with dmat->maxsize to preserve source-level compatibility with existing drivers. 2) Are there currently any serious plans to have bus_dmamem_alloc perform multi-segment allocations on non-IOMMU machines? It looks like NetBSD does this by reserving the physical segments and then stitching them together into a virtually contiguous range. Is something like this feasible for FreeBSD? 3) Are there currently any serious plans to support IOMMUs on anything besides Sun machines? The AMD AGP GART, PowerPC 970 DART, and Intel VT-d and AMD IOMMU all come to mind. If any of these ideas sound feasible, I'd be more than willing to help research/implement/test them. Thanks, Jason From ken at mthelicon.com Sun Jun 8 13:18:01 2008 From: ken at mthelicon.com (Pegasus Mc cleaft) Date: Sun Jun 8 13:18:31 2008 Subject: no -mno-sse3 in kernel build Message-ID: <200806081340.30132.ken@mthelicon.com> Hello everyone, Firstly, let me apologise if this message is not in the correct area, but I coulden't find a specific kernel section, so I thought this might be the best place. On my amd64 platform, I currently have built the world with -msse3 extensions enabled in my CFLAGS within /etc/make.conf. (I know the benefits of this are debatable, but I wanted to try and see what happened) I noticed that while the kernel was building (after the world build), there are many options sent that disable the mmx, sse and 3dnow extensions, but they only seem to override up to sse2.. Should there be a -mno-sse3 inserted in there as well? As it stands, I am running on a kernel built with sse3 extensions presumably enabled and nothing has gone bang yet, but that could be just a matter of time with the right load and applications running ;> Ta Ken From jmg at funkthat.com Wed Jun 11 18:49:32 2008 From: jmg at funkthat.com (John-Mark Gurney) Date: Wed Jun 11 18:49:35 2008 Subject: bus_dmamem_alloc In-Reply-To: <200806072341.17041.jason.harmening@gmail.com> References: <200806072341.17041.jason.harmening@gmail.com> Message-ID: <20080611182632.GT3767@funkthat.com> Jason Harmening wrote this message on Sat, Jun 07, 2008 at 23:41 -0500: > I've written a FreeBSD driver for Conexant CX2388x-based PCI TV capture cards. I have a partial one in P4 that seems to handle data transers fine, but as ATI never gave me the docs for programming the ATSC demodulator, I haven't worked on it in a long time.. > Of course the driver uses busdma to be as machine-independent as possible. > One problem I've encountered is that bus_dmamem_alloc is inadequate for my > needs. The CX2388x only understands 32-bit physical addreses, and the driver This restriction is set up by the dma tag... > has two separate use cases for busdma: > > 1) Data buffers: These buffers may be relatively large (a 640x480 RGB32 video > frame is ~1.2M), and therefore it is desirable that these buffers not be > physically contiguous. > > 2) DMA program buffers: The DMA engine on the CX2388x is controlled by > special-purpose RISC instructions, usually stored in host memory, that > provide information on, among other things, the physical layout of the data > buffers, which enables handling of non-contiguous data buffers. These > programs are rarely more than a few pages in size, so for the sake of > simplicity it is desirable that DMA program buffers be physically contiguous. Why not use the SRAM for this? That's what my driver does... w/ 32k SRAM, it's more than enough for more programs... > For case 1), I malloc(9) the buffers and then feed them to busdma, since on > most machines bus_dmamem_alloc just calls contigmalloc. Use of malloc(9) is > suboptimal as it may result in bounce buffering for non-IOMMU machines with > large amounts of RAM. I prefer to do direct to use DMA as it saves on allocating a buffer in the kernel, and then coping the data from that buffer... > For case 2), I contigmalloc the DMA program buffers in the 32-bit physical > address range and then feed them to busdma. I don't use bus_dmamem_alloc > here because it always allocates the maximum size specified in the > bus_dma_tag_t. Since the driver supports dynamic data buffer allocation and > DMA program generation, DMA program sizes may vary significantly. I > therefore just create the bus_dma_tag_t with the maximum possible size for a > DMA program buffer since I'd prefer not to have to re-create the tag every > time the DMA program size changes. But always allocating the maximum buffer > size would be a huge waste of contiguous memory, so bus_dmamem_alloc is out > of the question here too. At the same time, use of contigmalloc is > suboptimal as it may not be necessary to restrict the allocation to 32-bit > physical addresses on IOMMU-equipped machines. This is something that > bus_dmamem_alloc could take care of, if only it supported a size parameter > (as I believe the NetBSD version does). > > So I have 3 questions: > > 1) Would it be possible to provide a bus_dmamem_alloc overload that takes a > size parameter? We could call it bus_dmamem_alloc_size and have > bus_dmamem_alloc just call bus_dmamem_alloc_size with dmat->maxsize to > preserve source-level compatibility with existing drivers. It would be nice, but hasn't been something someone has gotten around to implementing yet... > 2) Are there currently any serious plans to have bus_dmamem_alloc perform > multi-segment allocations on non-IOMMU machines? It looks like NetBSD does > this by reserving the physical segments and then stitching them together into > a virtually contiguous range. Is something like this feasible for FreeBSD? This would be useful for large allocations, but for now our code works, and most IO isn't that large so it hasn't been a bit issue.. It would be nice though.. :) > 3) Are there currently any serious plans to support IOMMUs on anything besides > Sun machines? The AMD AGP GART, PowerPC 970 DART, and Intel VT-d and AMD > IOMMU all come to mind. I know that one person recently was working on Intel's VT IOMMU and I thought it was close to being committed, but I haven't been following the work... > If any of these ideas sound feasible, I'd be more than willing to help > research/implement/test them. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From jason.harmening at gmail.com Thu Jun 12 01:01:27 2008 From: jason.harmening at gmail.com (Jason Harmening) Date: Thu Jun 12 01:01:31 2008 Subject: bus_dmamem_alloc In-Reply-To: <20080611182632.GT3767@funkthat.com> References: <200806072341.17041.jason.harmening@gmail.com> <20080611182632.GT3767@funkthat.com> Message-ID: <200806112003.43326.jason.harmening@gmail.com> On Wednesday 11 June 2008, John-Mark Gurney wrote: > > Why not use the SRAM for this? That's what my driver does... w/ 32k > SRAM, it's more than enough for more programs... The DMA programs (or at least a significant chunk of them) will get stored in the SRAM, if there's enough room. That's often the case with just MPEG TS, but once you add analog video there's usually not enough room. > > > For case 1), I malloc(9) the buffers and then feed them to busdma, since > > on most machines bus_dmamem_alloc just calls contigmalloc. Use of > > malloc(9) is suboptimal as it may result in bounce buffering for > > non-IOMMU machines with large amounts of RAM. > > I prefer to do direct to use DMA as it saves on allocating a buffer in > the kernel, and then coping the data from that buffer... The driver actually supports both. Kernel-mode buffers are mmap'ed, so there shouldn't be a copy. Of course user-mode buffers can still bounce... > > 1) Would it be possible to provide a bus_dmamem_alloc overload that > > takes a size parameter? We could call it bus_dmamem_alloc_size and have > > bus_dmamem_alloc just call bus_dmamem_alloc_size with dmat->maxsize to > > preserve source-level compatibility with existing drivers. > > It would be nice, but hasn't been something someone has gotten around to > implementing yet... That's probably my only real complaint here--it seems like dmat->maxsize should just be a restriction, not an allocation unit. I don't want to sound ungrateful--busdma, at an API level at least, is great compared to what other OSes have to offer. > > I know that one person recently was working on Intel's VT IOMMU and I > thought it was close to being committed, but I haven't been following > the work... That'll be awesome when it's ready. From pisymbol at gmail.com Tue Jun 17 15:25:14 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Tue Jun 17 15:25:20 2008 Subject: Atheros (ath) MSI wireless embedded chipset fails to attach on 7.0-STABLE Message-ID: <3c0b01820806170757v5565b59ne0e9d5db06f26761@mail.gmail.com> Hello: I have installed FreeBSD-7.0-amd64 stable on my new AMD X2 Turon based notebook, a MSI-1710A (GX710Ax) which has a generic embedded controller. During boot up I notice that ATH complains with: ath_rate: version 1.2 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xfd7f0000-0xfd7fffff irq 16 at device 0.0 on pci2 ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfd7f0000 ath0: [MPSAFE] ath0: [ITHREAD] ath0: unable to attach hardware; HAL status 13 device_attach: ath0 attach returned 6 HAL status 13 from the header file seems to indicate that the 7.0-STABLE driver doesn't support my hardware revision. Here is my pciconf -l output: hostb0@pci0:0:0:0: class=0x060000 card=0x42cd1462 chip=0x79101002 rev=0x00 hdr=0x00 pcib1@pci0:0:2:0: class=0x060400 card=0x42cd1462 chip=0x79131002 rev=0x00 hdr=0x01 pcib2@pci0:0:4:0: class=0x060400 card=0x42cd1462 chip=0x79141002 rev=0x00 hdr=0x01 pcib3@pci0:0:6:0: class=0x060400 card=0x42cd1462 chip=0x79161002 rev=0x00 hdr=0x01 pcib4@pci0:0:7:0: class=0x060400 card=0x42cd1462 chip=0x79171002 rev=0x00 hdr=0x01 atapci0@pci0:0:18:0: class=0x01018f card=0x42cd1462 chip=0x43801002 rev=0x00 hdr=0x00 ohci0@pci0:0:19:0: class=0x0c0310 card=0x42cd1462 chip=0x43871002 rev=0x00 hdr=0x00 ohci1@pci0:0:19:1: class=0x0c0310 card=0x42cd1462 chip=0x43881002 rev=0x00 hdr=0x00 ohci2@pci0:0:19:2: class=0x0c0310 card=0x42cd1462 chip=0x43891002 rev=0x00 hdr=0x00 ohci3@pci0:0:19:3: class=0x0c0310 card=0x42cd1462 chip=0x438a1002 rev=0x00 hdr=0x00 ohci4@pci0:0:19:4: class=0x0c0310 card=0x42cd1462 chip=0x438b1002 rev=0x00 hdr=0x00 ehci0@pci0:0:19:5: class=0x0c0320 card=0x42cd1462 chip=0x43861002 rev=0x00 hdr=0x00 none0@pci0:0:20:0: class=0x0c0500 card=0x42cd1462 chip=0x43851002 rev=0x14 hdr=0x00 atapci1@pci0:0:20:1: class=0x01018a card=0x42cd1462 chip=0x438c1002 rev=0x00 hdr=0x00 none1@pci0:0:20:2: class=0x040300 card=0x42cd1462 chip=0x43831002 rev=0x00 hdr=0x00 isab0@pci0:0:20:3: class=0x060100 card=0x42cd1462 chip=0x438d1002 rev=0x00 hdr=0x00 pcib5@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 rev=0x00 hdr=0x01 hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vgapci0@pci0:1:0:0: class=0x030000 card=0x42cd1462 chip=0x95811002 rev=0x00 hdr=0x00 none2@pci0:1:0:1: class=0x040300 card=0xaa081462 chip=0xaa081002 rev=0x00 hdr=0x00 ath0@pci0:2:0:0: class=0x020000 card=0x10261a3b chip=0x001c168c rev=0x01 hdr=0x00 re0@pci0:5:0:0: class=0x020000 card=0x42cd1462 chip=0x816810ec rev=0x01 hdr=0x00 cbb0@pci0:6:4:0: class=0x060700 card=0x42cd1462 chip=0x71341217 rev=0x21 hdr=0x02 none3@pci0:6:4:2: class=0x080500 card=0x42cd1462 chip=0x71201217 rev=0x01 hdr=0x00 none4@pci0:6:4:3: class=0x068000 card=0x42cd1462 chip=0x71301217 rev=0x01 hdr=0x00 fwohci0@pci0:6:4:4: class=0x0c0010 card=0x42cd1462 chip=0x00f71217 rev=0x02 hdr=0x00 ath0 is listed as rev=0x01 so I'm a little confused why I got HAL status 13. Does anyone know if this chipset is supported in 7.0-STABLE? If not, is it possible to try CURRENT on 7.0 which may fix it? I've attached my complete dmesg output. Again, any feedback would be much appreciated! -aps -------------- next part -------------- A non-text attachment was scrubbed... Name: unity-dmesg Type: application/octet-stream Size: 37732 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-drivers/attachments/20080617/edf2a0e1/unity-dmesg.obj From pisymbol at gmail.com Tue Jun 17 19:46:46 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Tue Jun 17 19:46:49 2008 Subject: Atheros (ath) MSI wireless embedded chipset fails to attach on 7.0-STABLE In-Reply-To: <20080617143554.1808562gg94i8ikg@intranet.casasponti.net> References: <3c0b01820806170757v5565b59ne0e9d5db06f26761@mail.gmail.com> <4857D8BB.1080901@gmail.com> <3c0b01820806170852t39a6346doa6d77a655469eed9@mail.gmail.com> <20080617135900.18654t73s6d7sfqc@intranet.casasponti.net> <48580EB9.7090701@gmail.com> <20080617143554.1808562gg94i8ikg@intranet.casasponti.net> Message-ID: <3c0b01820806171244g6f2ba46ybe0ba6d89eaab13b@mail.gmail.com> On Tue, Jun 17, 2008 at 3:35 PM, Edwin L. Culp wrote: > "Manolis Kiagias" escribi?: > >> Edwin L. Culp wrote: >>> >>> "Alexander Sack" escribi?: >>> >>>> On Tue, Jun 17, 2008 at 11:31 AM, Manolis Kiagias >>>> wrote: >>>>> >>>>> Alexander Sack wrote: >>>>>> >>>>>> Hello: >>>>>> >>>>>> I have installed FreeBSD-7.0-amd64 stable on my new AMD X2 Turon based >>>>>> notebook, a MSI-1710A (GX710Ax) which has a generic embedded >>>>>> controller. During boot up I notice that ATH complains with: >>>>>> >>>>>> ath_rate: version 1.2 >>>>>> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, >>>>>> RF5413) >>>>>> ath0: mem 0xfd7f0000-0xfd7fffff irq 16 at device >>>>>> 0.0 >>>>>> on pci2 >>>>>> ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfd7f0000 >>>>>> ath0: [MPSAFE] >>>>>> ath0: [ITHREAD] >>>>>> ath0: unable to attach hardware; HAL status 13 >>>>>> device_attach: ath0 attach returned 6 >>>>>> >>>>>> HAL status 13 from the header file seems to indicate that the >>>>>> 7.0-STABLE driver doesn't support my hardware revision. Here is my >>>>>> pciconf -l output: >>>>>> >>>>> >>>>> Maybe you could try compiling a kernel with a newer hal. This is the >>>>> kind of >>>>> hack we use on the eeepc. Have a look at this: >>>>> >>>>> http://nighthack.org/wiki/EeeBSD >>>> >>>> Thank you SO much for this link. That's EXACTLY what I want to do >>>> because I realize that this is a HAL problem. I've been searching >>>> like MAD where I could get an updated binary HAL for this chipset >>>> (PCIe based). >>> >>> That makes two of us ;) >>> >>> My dmesg is very, very similar to yours and hoped that this would work. >>> >>> ath0: mem 0xf2200000-0xf220ffff irq 19 at device 0.0 >>> on pci5 >>> ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf2200000 >>> ioapic0: routing intpin 19 (PCI IRQ 19) to vector 64 >>> ath0: [MPSAFE] >>> ath0: [ITHREAD] >>> ath0: unable to attach hardware; HAL status 13 >>> device_attach: ath0 attach returned 6 >>> >>> I followed the instructions from the web page, recompiled and it made no >>> difference which really worries me that I must have done something wrong. >>> >>> cd madwifi-ng-r2756+ar5007/hal >>> cp -R * /usr/src/sys/contrib/dev/ath/ >>> >>> I did not erase it previously but am going to try that. I made no kern >>> configuration changes to find that the hal is from contrib. Is there >>> nothing else I should do? >>> >>> Thanks, >>> >> >> Well, I have only tested this on the eeepc and can confirm it works. >> Maybe different atheros chipset have other problems not directly related >> to the hal version. >> You do not need to do anything more that what is shown in the page: untar, >> replace the existing files, recompile / install kernel, reboot. If you got >> no errors during the kernel compilation phase, you can safely assume you did >> everything correctly, and the problem lies elsewhere. > > At least there was a ray of hope for the time it took to compile the kernel. Ed: I took recompiled and got the same issue. If I use the LATEST mad distro I get some compile bugs (ath_desc_status was moved into ath_desc structure in ah_desc.h) which I can't completely work around (apparently the API into the HAL has changed as well). What I'm trying to do is look at the Linux driver and understand the newer API in order to get past this compile issue and see if this works. Otherwise I believe we are SOL. Does anyone know if the CURRENT contains an updated ath HAL AND driver for support of newer PCIe based chipsets? If I get it to work I will let you know... -aps From pisymbol at gmail.com Tue Jun 17 21:17:44 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Tue Jun 17 21:17:48 2008 Subject: Atheros (ath) MSI wireless embedded chipset fails to attach on 7.0-STABLE In-Reply-To: <3c0b01820806171244g6f2ba46ybe0ba6d89eaab13b@mail.gmail.com> References: <3c0b01820806170757v5565b59ne0e9d5db06f26761@mail.gmail.com> <4857D8BB.1080901@gmail.com> <3c0b01820806170852t39a6346doa6d77a655469eed9@mail.gmail.com> <20080617135900.18654t73s6d7sfqc@intranet.casasponti.net> <48580EB9.7090701@gmail.com> <20080617143554.1808562gg94i8ikg@intranet.casasponti.net> <3c0b01820806171244g6f2ba46ybe0ba6d89eaab13b@mail.gmail.com> Message-ID: <3c0b01820806171417l2b054e15i5627d88827cc03b4@mail.gmail.com> On Tue, Jun 17, 2008 at 3:44 PM, Alexander Sack wrote: > On Tue, Jun 17, 2008 at 3:35 PM, Edwin L. Culp wrote: >> "Manolis Kiagias" escribi?: >> >>> Edwin L. Culp wrote: >>>> >>>> "Alexander Sack" escribi?: >>>> >>>>> On Tue, Jun 17, 2008 at 11:31 AM, Manolis Kiagias >>>>> wrote: >>>>>> >>>>>> Alexander Sack wrote: >>>>>>> >>>>>>> Hello: >>>>>>> >>>>>>> I have installed FreeBSD-7.0-amd64 stable on my new AMD X2 Turon based >>>>>>> notebook, a MSI-1710A (GX710Ax) which has a generic embedded >>>>>>> controller. During boot up I notice that ATH complains with: >>>>>>> >>>>>>> ath_rate: version 1.2 >>>>>>> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, >>>>>>> RF5413) >>>>>>> ath0: mem 0xfd7f0000-0xfd7fffff irq 16 at device >>>>>>> 0.0 >>>>>>> on pci2 >>>>>>> ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfd7f0000 >>>>>>> ath0: [MPSAFE] >>>>>>> ath0: [ITHREAD] >>>>>>> ath0: unable to attach hardware; HAL status 13 >>>>>>> device_attach: ath0 attach returned 6 >>>>>>> >>>>>>> HAL status 13 from the header file seems to indicate that the >>>>>>> 7.0-STABLE driver doesn't support my hardware revision. Here is my >>>>>>> pciconf -l output: >>>>>>> >>>>>> >>>>>> Maybe you could try compiling a kernel with a newer hal. This is the >>>>>> kind of >>>>>> hack we use on the eeepc. Have a look at this: >>>>>> >>>>>> http://nighthack.org/wiki/EeeBSD >>>>> >>>>> Thank you SO much for this link. That's EXACTLY what I want to do >>>>> because I realize that this is a HAL problem. I've been searching >>>>> like MAD where I could get an updated binary HAL for this chipset >>>>> (PCIe based). >>>> >>>> That makes two of us ;) >>>> >>>> My dmesg is very, very similar to yours and hoped that this would work. >>>> >>>> ath0: mem 0xf2200000-0xf220ffff irq 19 at device 0.0 >>>> on pci5 >>>> ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf2200000 >>>> ioapic0: routing intpin 19 (PCI IRQ 19) to vector 64 >>>> ath0: [MPSAFE] >>>> ath0: [ITHREAD] >>>> ath0: unable to attach hardware; HAL status 13 >>>> device_attach: ath0 attach returned 6 >>>> >>>> I followed the instructions from the web page, recompiled and it made no >>>> difference which really worries me that I must have done something wrong. >>>> >>>> cd madwifi-ng-r2756+ar5007/hal >>>> cp -R * /usr/src/sys/contrib/dev/ath/ >>>> >>>> I did not erase it previously but am going to try that. I made no kern >>>> configuration changes to find that the hal is from contrib. Is there >>>> nothing else I should do? >>>> >>>> Thanks, >>>> >>> >>> Well, I have only tested this on the eeepc and can confirm it works. >>> Maybe different atheros chipset have other problems not directly related >>> to the hal version. >>> You do not need to do anything more that what is shown in the page: untar, >>> replace the existing files, recompile / install kernel, reboot. If you got >>> no errors during the kernel compilation phase, you can safely assume you did >>> everything correctly, and the problem lies elsewhere. >> >> At least there was a ray of hope for the time it took to compile the kernel. > > Ed: > > I took recompiled and got the same issue. If I use the LATEST mad > distro I get some compile bugs (ath_desc_status was moved into > ath_desc structure in ah_desc.h) which I can't completely work around > (apparently the API into the HAL has changed as well). What I'm > trying to do is look at the Linux driver and understand the newer API > in order to get past this compile issue and see if this works. > Otherwise I believe we are SOL. > > Does anyone know if the CURRENT contains an updated ath HAL AND driver > for support of newer PCIe based chipsets? > > If I get it to work I will let you know... > Ok the trick is not to get it from the madfi project. Get it from the author directly! If you grab: http://people.freebsd.org/~sam/ath_hal-20080528.tgz Copy the contents into the src/sys/contrib/dev/ath/* and recompile, you should now see ath attach properly to the your NIC card. Thanks go to my friend jkim for pointing this out since he has a similar notebook/chipset and runs CURRENT successfully. I tried using CURRENT ath but there is to much vap support in it and it turned out the 7.0-RELEASE driver works. Now ath attaches properly and I'm going to test it out! (this is at least much further than a bad attach status code from the HAL). Let me know how it goes, -aps From pisymbol at gmail.com Tue Jun 17 23:48:21 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Tue Jun 17 23:48:27 2008 Subject: Atheros (ath) MSI wireless embedded chipset fails to attach on 7.0-STABLE In-Reply-To: <3c0b01820806171417l2b054e15i5627d88827cc03b4@mail.gmail.com> References: <3c0b01820806170757v5565b59ne0e9d5db06f26761@mail.gmail.com> <4857D8BB.1080901@gmail.com> <3c0b01820806170852t39a6346doa6d77a655469eed9@mail.gmail.com> <20080617135900.18654t73s6d7sfqc@intranet.casasponti.net> <48580EB9.7090701@gmail.com> <20080617143554.1808562gg94i8ikg@intranet.casasponti.net> <3c0b01820806171244g6f2ba46ybe0ba6d89eaab13b@mail.gmail.com> <3c0b01820806171417l2b054e15i5627d88827cc03b4@mail.gmail.com> Message-ID: <3c0b01820806171648g7cc01476l30df79831f9b9c6@mail.gmail.com> Final update, I got everything working! I came home and connected by new notebook using the latest PCIe Atheros chipset to a WPA2 network using wpa_supplicant! Yippie! Hope this thread helps someone else, -aps On Tue, Jun 17, 2008 at 5:17 PM, Alexander Sack wrote: > On Tue, Jun 17, 2008 at 3:44 PM, Alexander Sack wrote: >> On Tue, Jun 17, 2008 at 3:35 PM, Edwin L. Culp wrote: >>> "Manolis Kiagias" escribi?: >>> >>>> Edwin L. Culp wrote: >>>>> >>>>> "Alexander Sack" escribi?: >>>>> >>>>>> On Tue, Jun 17, 2008 at 11:31 AM, Manolis Kiagias >>>>>> wrote: >>>>>>> >>>>>>> Alexander Sack wrote: >>>>>>>> >>>>>>>> Hello: >>>>>>>> >>>>>>>> I have installed FreeBSD-7.0-amd64 stable on my new AMD X2 Turon based >>>>>>>> notebook, a MSI-1710A (GX710Ax) which has a generic embedded >>>>>>>> controller. During boot up I notice that ATH complains with: >>>>>>>> >>>>>>>> ath_rate: version 1.2 >>>>>>>> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, >>>>>>>> RF5413) >>>>>>>> ath0: mem 0xfd7f0000-0xfd7fffff irq 16 at device >>>>>>>> 0.0 >>>>>>>> on pci2 >>>>>>>> ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfd7f0000 >>>>>>>> ath0: [MPSAFE] >>>>>>>> ath0: [ITHREAD] >>>>>>>> ath0: unable to attach hardware; HAL status 13 >>>>>>>> device_attach: ath0 attach returned 6 >>>>>>>> >>>>>>>> HAL status 13 from the header file seems to indicate that the >>>>>>>> 7.0-STABLE driver doesn't support my hardware revision. Here is my >>>>>>>> pciconf -l output: >>>>>>>> >>>>>>> >>>>>>> Maybe you could try compiling a kernel with a newer hal. This is the >>>>>>> kind of >>>>>>> hack we use on the eeepc. Have a look at this: >>>>>>> >>>>>>> http://nighthack.org/wiki/EeeBSD >>>>>> >>>>>> Thank you SO much for this link. That's EXACTLY what I want to do >>>>>> because I realize that this is a HAL problem. I've been searching >>>>>> like MAD where I could get an updated binary HAL for this chipset >>>>>> (PCIe based). >>>>> >>>>> That makes two of us ;) >>>>> >>>>> My dmesg is very, very similar to yours and hoped that this would work. >>>>> >>>>> ath0: mem 0xf2200000-0xf220ffff irq 19 at device 0.0 >>>>> on pci5 >>>>> ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf2200000 >>>>> ioapic0: routing intpin 19 (PCI IRQ 19) to vector 64 >>>>> ath0: [MPSAFE] >>>>> ath0: [ITHREAD] >>>>> ath0: unable to attach hardware; HAL status 13 >>>>> device_attach: ath0 attach returned 6 >>>>> >>>>> I followed the instructions from the web page, recompiled and it made no >>>>> difference which really worries me that I must have done something wrong. >>>>> >>>>> cd madwifi-ng-r2756+ar5007/hal >>>>> cp -R * /usr/src/sys/contrib/dev/ath/ >>>>> >>>>> I did not erase it previously but am going to try that. I made no kern >>>>> configuration changes to find that the hal is from contrib. Is there >>>>> nothing else I should do? >>>>> >>>>> Thanks, >>>>> >>>> >>>> Well, I have only tested this on the eeepc and can confirm it works. >>>> Maybe different atheros chipset have other problems not directly related >>>> to the hal version. >>>> You do not need to do anything more that what is shown in the page: untar, >>>> replace the existing files, recompile / install kernel, reboot. If you got >>>> no errors during the kernel compilation phase, you can safely assume you did >>>> everything correctly, and the problem lies elsewhere. >>> >>> At least there was a ray of hope for the time it took to compile the kernel. >> >> Ed: >> >> I took recompiled and got the same issue. If I use the LATEST mad >> distro I get some compile bugs (ath_desc_status was moved into >> ath_desc structure in ah_desc.h) which I can't completely work around >> (apparently the API into the HAL has changed as well). What I'm >> trying to do is look at the Linux driver and understand the newer API >> in order to get past this compile issue and see if this works. >> Otherwise I believe we are SOL. >> >> Does anyone know if the CURRENT contains an updated ath HAL AND driver >> for support of newer PCIe based chipsets? >> >> If I get it to work I will let you know... >> > > Ok the trick is not to get it from the madfi project. Get it from the > author directly! > > If you grab: > > http://people.freebsd.org/~sam/ath_hal-20080528.tgz > > Copy the contents into the src/sys/contrib/dev/ath/* and recompile, > you should now see ath attach properly to the your NIC card. Thanks > go to my friend jkim for pointing this out since he has a similar > notebook/chipset and runs CURRENT successfully. I tried using CURRENT > ath but there is to much vap support in it and it turned out the > 7.0-RELEASE driver works. > > Now ath attaches properly and I'm going to test it out! (this is at > least much further than a bad attach status code from the HAL). > > Let me know how it goes, > > -aps > From karimulla at krify.com Wed Jun 25 07:50:09 2008 From: karimulla at krify.com (karim sk) Date: Wed Jun 25 07:50:12 2008 Subject: Creating driver update disks (driver disks) Message-ID: <20080625001814.BD63695B@resin17.mta.everyone.net> Hi, Anybody knows how to create driver disks for FreeBSD ? I want to ask one more question, "Whether FreeBSD allows to supply driver disks at the installation time, so that installation media sees the new hardware ?" Thanks in advance. Karim _________________________________________________________________ I use Krify Mail - http://mail.krify.com Get yourmail at Krify today! From Benjamin.Close at clearchain.com Thu Jun 26 16:02:07 2008 From: Benjamin.Close at clearchain.com (Benjamin Close) Date: Thu Jun 26 16:02:12 2008 Subject: Creating driver update disks (driver disks) In-Reply-To: <20080625001814.BD63695B@resin17.mta.everyone.net> References: <20080625001814.BD63695B@resin17.mta.everyone.net> Message-ID: <4863B9E9.8010803@clearchain.com> karim sk wrote: > Hi, > Anybody knows how to create driver disks for FreeBSD ? > I want to ask one more question, "Whether FreeBSD allows to supply > driver disks at the installation time, so that installation media sees > the new hardware ?" > Thanks in advance. > Karim > FreeBSD generally doesn't have driver disks. If you tell us what hardware isn't being detected, we might be able to help :) Cheers, Benjamin