Re: RTL8168/8111 PCI express support
On 6/11/08, Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > On Tue, Jun 10, 2008 at 03:11:22PM -0700, Jeremy Chadwick wrote: > > On Tue, Jun 10, 2008 at 11:08:05PM +0200, Fernando Apestegu?a wrote: > > > I sent this mail to freebsd-questions but I got no answer. I hope you > > > can help me. > > > > > > I got a computer with an RTL8168/8111 PCI Express NIC. It is shown in > > > pciconf but it is not seen by FreeBSD 7. I'm using i386 arch. > > > > > > I have re and rl drivers compiled in the kernel (stock GENERIC kernel, > > > actually). > > > > > > What do I need to make the NIC work properly? > > > > CC'ing PYUN YongHyeon, who should be able to help, since he helps > > maintain the driver. :-) > > I don't know which revision of RealTek controller you have. Just > knowing "pciconf -lv" is not enough. Since 7.0 didn't recognize > your controller I guess it could be newer revision from RealTek. > There is a WIP version that try to add support for newer > controllers. In order to try the WIP version you have to update to > latest 7-stable first and apply the following patch. > > http://people.freebsd.org/~yongari/re/re.HEAD.20080610 > > The patch still have some issues but it should detect/recognize > your controller. It makes sense what you say about the new revision cause the whole computer is quite new. In any case I will paste the "pciconf -lv" output just to be sure of the controller I have. I already have the 7-stable system installed with the kernel sources installed from sysinstall. Do I need any update of the source code? Thanks in advance. > > > > > I'd recommend you start by providing pciconf -lv output here. > > > > -- > > | Jeremy Chadwickjdc at parodius.com | > > | Parodius Networking http://www.parodius.com/ | > > | UNIX Systems Administrator Mountain View, CA, USA | > > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > > > -- > Regards, > Pyun YongHyeon > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[RFC] patch to AHCI device detection code
Hi, Soren.
I'm found solution for AHCI that solve ATAPI device detection for me.
I just added waiting loop on PxTFD after reset and now my SATA DVD
detected well. Waiting time (in my case) may vary from 1ms to 900 ms.
Also AHCI spec says:
10.4.2 Port Reset
...
When PxSCTL.DET is set to 0h, upon receiving a COMINIT from
the attached device, PxTFD.STS.BSY shall be set to ’1’ by the HBA.
So we can wait until PxTFD.STS.BSY resets to zero and then
read PxSIG.
Any comments?
--
WBR, Andrey V. Elsukov
Index: src/sys/dev/ata/ata-chipset.c
===
RCS file: /ncvs/src/sys/dev/ata/ata-chipset.c,v
retrieving revision 1.219
diff -u -b -p -r1.219 ata-chipset.c
--- src/sys/dev/ata/ata-chipset.c 21 Apr 2008 10:51:38 - 1.219
+++ src/sys/dev/ata/ata-chipset.c 11 Jun 2008 07:17:53 -
@@ -1059,10 +1059,10 @@ ata_ahci_softreset(device_t dev, int por
struct ata_pci_controller *ctlr = device_get_softc(device_get_parent(dev));
struct ata_channel *ch = device_get_softc(dev);
int offset = ch->unit << 7;
+int timeout = 0;
#ifdef AHCI_PM
struct ata_ahci_cmd_tab *ctp =
(struct ata_ahci_cmd_tab *)(ch->dma.work + ATA_AHCI_CT_OFFSET);
-int timeout = 0;
/* kick controller into sane state if needed */
ata_ahci_restart(dev);
@@ -1091,6 +1091,7 @@ ata_ahci_softreset(device_t dev, int por
ata_udelay(15);
+#endif
timeout = 0;
do {
DELAY(1000);
@@ -1101,7 +1102,6 @@ ata_ahci_softreset(device_t dev, int por
} while (ATA_INL(ctlr->r_res2, ATA_AHCI_P_TFD + offset) & ATA_S_BUSY);
if (bootverbose)
device_printf(dev, "BUSY wait time=%dms\n", timeout);
-#endif
return ATA_INL(ctlr->r_res2, ATA_AHCI_P_SIG + offset);
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [RFC] patch to AHCI device detection code
Andrey V. Elsukov wrote: Hi, Soren. Hi, All too :) Not so long Soren said that he is losing emails, so i added freebsd-hackers@ list to be heard. -- WBR, Andrey V. Elsukov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [RFC] patch to AHCI device detection code
Hi
Well, as you can see I tried this when I added the PM code to AHCI,
however one of the reasons I left it out again (for now) is that it
doesn't work on more than about 50% of the AHCI chipsets out there..
Modern HW in a nutshell, you win some you loose some ;)
-Søren
On 11Jun, 2008, at 9:30 , Andrey V. Elsukov wrote:
Hi, Soren.
I'm found solution for AHCI that solve ATAPI device detection for me.
I just added waiting loop on PxTFD after reset and now my SATA DVD
detected well. Waiting time (in my case) may vary from 1ms to 900 ms.
Also AHCI spec says:
10.4.2 Port Reset
...
When PxSCTL.DET is set to 0h, upon receiving a COMINIT from
the attached device, PxTFD.STS.BSY shall be set to ’1’ by the HBA.
So we can wait until PxTFD.STS.BSY resets to zero and then
read PxSIG.
Any comments?
--
WBR, Andrey V. Elsukov
Index: src/sys/dev/ata/ata-chipset.c
===
RCS file: /ncvs/src/sys/dev/ata/ata-chipset.c,v
retrieving revision 1.219
diff -u -b -p -r1.219 ata-chipset.c
--- src/sys/dev/ata/ata-chipset.c 21 Apr 2008 10:51:38 - 1.219
+++ src/sys/dev/ata/ata-chipset.c 11 Jun 2008 07:17:53 -
@@ -1059,10 +1059,10 @@ ata_ahci_softreset(device_t dev, int por
struct ata_pci_controller *ctlr =
device_get_softc(device_get_parent(dev));
struct ata_channel *ch = device_get_softc(dev);
int offset = ch->unit << 7;
+int timeout = 0;
#ifdef AHCI_PM
struct ata_ahci_cmd_tab *ctp =
(struct ata_ahci_cmd_tab *)(ch->dma.work + ATA_AHCI_CT_OFFSET);
-int timeout = 0;
/* kick controller into sane state if needed */
ata_ahci_restart(dev);
@@ -1091,6 +1091,7 @@ ata_ahci_softreset(device_t dev, int por
ata_udelay(15);
+#endif
timeout = 0;
do {
DELAY(1000);
@@ -1101,7 +1102,6 @@ ata_ahci_softreset(device_t dev, int por
} while (ATA_INL(ctlr->r_res2, ATA_AHCI_P_TFD + offset) &
ATA_S_BUSY);
if (bootverbose)
device_printf(dev, "BUSY wait time=%dms\n", timeout);
-#endif
return ATA_INL(ctlr->r_res2, ATA_AHCI_P_SIG + offset);
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [RFC] patch to AHCI device detection code
Søren Schmidt wrote: Well, as you can see I tried this when I added the PM code to AHCI, however one of the reasons I left it out again (for now) is that it doesn't work on more than about 50% of the AHCI chipsets out there.. Modern HW in a nutshell, you win some you loose some ;) Hm.. I think it can't made regression. I don't see nothing dangerous in addition 1s waiting (it doesn't enable softreset code, only PxTFD reading loop).. -- WBR, Andrey V. Elsukov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [RFC] patch to AHCI device detection code
Hi You are right on that one of course, from my quick eyeballing the patch I thought you enabled the reset sequence too, but on a closer look its only the extra timeout, my bad. However, the most usual problem is that the devices does not leave a signature behind due to the missing reset sequence. That problem is 50/50 as some controllers apparently doesn't like the resetting and will leave busy set and a hanging channel. I'll be getting some new HW here in the lab tomorrow if all goes well, that will let me play with this on one of the failing devices again. Maybe I'll find a generic solution this time around. I'll commit this patch for now, as you said, it doesn't hurt.. -Søren On 11Jun, 2008, at 10:00 , Andrey V. Elsukov wrote: Søren Schmidt wrote: Well, as you can see I tried this when I added the PM code to AHCI, however one of the reasons I left it out again (for now) is that it doesn't work on more than about 50% of the AHCI chipsets out there.. Modern HW in a nutshell, you win some you loose some ;) Hm.. I think it can't made regression. I don't see nothing dangerous in addition 1s waiting (it doesn't enable softreset code, only PxTFD reading loop).. -- WBR, Andrey V. Elsukov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bus_dmamem_alloc
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." ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kerberized CIFS client?
On Sun, 08 Jun 2008, Atte Peltomki wrote: >smbclient (and other samba utilities) do not refer to krb5.conf when >figuring out the kerberos realm. > >you will have to put to your krb5.conf on both client and server: > >[domain_realms] >cifs.example.com = realm.example.com I've done this step, but there seems to be no difference. When I did a tcpdump and viewed the results in wireshark there was no attempt to do anything kerberos related, the first thing related to auth mentioned was NTLM. I don't see anything with lsknobs or make config. Am I missing something? -Derek. >Otherwise it will just try to use example.com as the realm. > >On 6/6/08, Derek Taylor <[EMAIL PROTECTED]> wrote: >> On Tue, 03 Jun 2008, Atte Peltomki wrote: >>>You will have to adjust your krb5.conf to map a given domain or hostname >>>to a kerberos realm, if you are doing cross-realm authentication. See MIT >>>kerberos admin guide for details. >> >> I'm pretty sure it's set up ok. I can use smbclient -k just fine: >> $ kinit >> [EMAIL PROTECTED]'s Password: >> kinit: NOTICE: ticket renewable lifetime is 1 week >> $ klist >> Credentials cache: FILE:/tmp/krb5cc_1001 >> Principal: [EMAIL PROTECTED] >> >> Issued Expires Principal >> Jun 6 15:08:47 Jun 7 01:08:47 krbtgt/[EMAIL PROTECTED] >> $ smbclient -k -U det135 //cifs.example.com/dir1 >> OS=[Unix] Server=[Samba 3.0.30] >> smb: \> ls >> . D0 Thu Feb 14 14:46:42 2008 >> .. D0 Fri Jun 6 10:16:29 2008 >> [ other files/directories here ] >> >> smb: \> quit >> $ cd ~/mount/smbbeta.pass.psu.edu/pass >> $ ls >> ls: .: Permission denied >> $ klist >> Credentials cache: FILE:/tmp/krb5cc_1001 >> Principal: [EMAIL PROTECTED] >> >> Issued Expires Principal >> Jun 6 15:08:47 Jun 7 01:08:47 krbtgt/[EMAIL PROTECTED] >> Jun 6 15:09:17 Jun 7 01:08:47 cifs/[EMAIL PROTECTED] >> $ >> >> -Derek. >> >>>On 6/3/08, Derek Taylor <[EMAIL PROTECTED]> wrote: On Tue, 03 Jun 2008, Harti Brandt wrote: >On Tue, 3 Jun 2008, Derek Taylor wrote: > >DT>On Thu, 22 May 2008, Hartmut Brandt wrote: >DT>>Derek Taylor wrote: >DT>>> This question was previously posed of the freebsd-questions list, > but >DT>>> with no response for a week, I'd like to try my luck here. If > there's >DT>>> any more information I should include, please speak up: I would be > glad >DT>>> to oblige. >DT>>> >DT>>> I would like to use smb/cifs with kerberos auth, but mount_smbfs > doesn't >DT>>> seem to support this. >DT>>> >DT>>> Is anyone aware of an alternate means of performing a mount via > smb/cifs >DT>>> or any patches to provide such functionality? >DT>>> >DT>>> I already have smbclient working with -k, but I am also interested > in > a >DT>>> mount. >DT>> >DT>>Try smbnetfs from ports. It's fuse based and seems to work very nice. > If >DT>>you have a large amount of shares floating in your network you want > to >DT>>restrict it to mount only the needed shares via the config file. >DT>>Otherwise it will mount what it can find... >DT>> >DT>>It plays nicely with kerberors. When your ticket expires you > immediately >DT>>loose access; when you renew it you gain access again. All without > the >DT>>need to unmount/mount. Just call smbnetfs once you have your ticket. > You >DT>>may even do this from your .profile. >DT>> >DT>>harti >DT> >DT>Sorry for not replying sooner. >DT> >DT>Initial tests here are promising (I can see some mount paths being >DT>exported from the server), but it's not fully working (I don't see all >DT>of the mount paths that *should* be exported and I get permission > denied >DT>errors). My thoughts are leaning towards an issue in negotiating auth >DT>with the server -- perhaps my krb creds aren't being used? > >You can test this easily: if your ticket expires you get permission > denied >errors when you try to look into the mounted directories. As soon as you >renew the ticket you get access again. All without restarting smbnetfs. > >harti I replaced all server names below with "example.com" (and derivatives) where appropriate: From my FreeBSD machine, using smbnetfs: $ klist klist: No ticket file: /tmp/krb5cc_1001 $ kinit det135 [EMAIL PROTECTED]'s Password: kinit: NOTICE: ticket renewable lifetime is 1 week $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: [EMAIL PROTECTED] Issued Expires Principal Jun 3 11:51:20 Jun 3 21:51:04 krbtgt/[EMAIL PROTECTED] $ cd ~/mount/cifs.example.com/dir1 $ ls ls: .: Permission denied $ cd .. $ ls dir1 dir2 $ klist Credentials cach
Re: bus_dmamem_alloc
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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RTL8168/8111 PCI express support
On Wed, Jun 11, 2008 at 09:13:24AM +0200, Fernando Apestegu?a wrote: > On 6/11/08, Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > > On Tue, Jun 10, 2008 at 03:11:22PM -0700, Jeremy Chadwick wrote: > > > On Tue, Jun 10, 2008 at 11:08:05PM +0200, Fernando Apestegu?a wrote: > > > > I sent this mail to freebsd-questions but I got no answer. I hope you > > > > can help me. > > > > > > > > I got a computer with an RTL8168/8111 PCI Express NIC. It is shown in > > > > pciconf but it is not seen by FreeBSD 7. I'm using i386 arch. > > > > > > > > I have re and rl drivers compiled in the kernel (stock GENERIC kernel, > > > > actually). > > > > > > > > What do I need to make the NIC work properly? > > > > > > CC'ing PYUN YongHyeon, who should be able to help, since he helps > > > maintain the driver. :-) > > > > I don't know which revision of RealTek controller you have. Just > > knowing "pciconf -lv" is not enough. Since 7.0 didn't recognize > > your controller I guess it could be newer revision from RealTek. > > There is a WIP version that try to add support for newer > > controllers. In order to try the WIP version you have to update to > > latest 7-stable first and apply the following patch. > > > > http://people.freebsd.org/~yongari/re/re.HEAD.20080610 > > > > The patch still have some issues but it should detect/recognize > > your controller. > > > It makes sense what you say about the new revision cause the whole > computer is quite new. In any case I will paste the "pciconf -lv" > output just to be sure of the controller I have. > > I already have the 7-stable system installed with the kernel sources > installed from sysinstall. Do I need any update of the source code? > If you use 7-stable, you may not have to update again. Just apply patche above and let me know the result. > Thanks in advance. > > > > > > > > > I'd recommend you start by providing pciconf -lv output here. > > > > > > -- > > > | Jeremy Chadwickjdc at parodius.com | > > > | Parodius Networking http://www.parodius.com/ | > > > | UNIX Systems Administrator Mountain View, CA, USA | > > > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > > -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
