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: DTOn Thu, 22 May 2008, Hartmut Brandt wrote: DTDerek 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 DTTry smbnetfs from ports. It's fuse based and seems to work very nice. If DTyou have a large amount of shares floating in your network you want to DTrestrict it to mount only the needed shares via the config file. DTOtherwise it will mount what it can find... DT DTIt plays nicely with kerberors. When your ticket expires you immediately DTloose access; when you renew it you gain access again. All without the DTneed to unmount/mount. Just call smbnetfs once you have your ticket. You DTmay even do this from your .profile. DT DTharti DT DTSorry for not replying sooner. DT DTInitial tests here are promising (I can see some mount paths being DTexported from the server), but it's not fully working (I don't see all DTof the mount paths that *should* be exported and I get permission denied DTerrors). My thoughts are leaning towards an issue in negotiating auth DTwith 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 cache: FILE:/tmp/krb5cc_1001 Principal: [EMAIL PROTECTED] Issued Expires Principal Jun 3 11:51:20 Jun 3 21:51:04 krbtgt/[EMAIL PROTECTED] From my Mac, using (from Finder) Go - Connect to Server - cifs://cifs.example.com/dir1 $ klist klist: No Kerberos 5 tickets in credentials cache $ kinit det135 Please enter the password for [EMAIL PROTECTED]: $ klist Kerberos 5 ticket cache: 'API:Initial default ccache' Default principal: [EMAIL PROTECTED] Valid Starting ExpiresService Principal 06/03/08
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]
