Hi, I have RTL8168H (pciex10ec,8161)not working with the driver on illumos/SmartOS and RTL8111C (pciex10ec,8168) network card working. Are they really that different and 8161/RTL8168H have no driver under illumos, or is it just an PCI-e ID to be mapped to driver.

I used to add PCI id to some file , back on OI, for a wireless card to start working. maybe i could do the same if ' rge ' driver actually works with it , until it is fixed in illumos or SmartOS

well, you can test that hypothesis by running "update_drv -a -i pciex10ec,8161 rge"

Woodstock, great :) thanks. rge recognized the card (again) and it is seen in dladm show-phys

nikolam: if it also works, you can file a feature request, and if you feel up to it you can even modify usr/src/pkg/manifests/driver-network-rge.p5m to include the new pci id by default and post it for review :)

Of course, because network card is not initialized, because it were not attached to rge on boot

Obviously I would need also some functionality testing, e.g. making the change permanent in current install for testing

it's permanent in your BE after you ran update_drv

sure Woodstock I am in SmartOS and I boot from USB drive usually and I think root is read only if booting from HD / piadm . Maybe I can test on other machine with omnios and beadm.

ok, on SmartOS this won't persist, of course :)

if it appears to work, tests are good, then we can commit the change to gate and smartos will get it from there.

hrm.. github.com/illumos/illumos-gate/blo…nnel/fca/emlxs/emlxs_fc.h#L737-L934 -- couldn't those be replaced with a call to ddi_fls() ?

(or maybe coupled with a couple of statements to clamp the result

hrm.. i don't suppose any sun alumni might know what 'tigershark' might be referring to?

this is odd.. panic in tem because the STREAMS queue seems wrong

it's showing a part of the iphelper module

think tigershark is an FC adaptor

rather than anying upstream of one

but that's from 3 bugs referring to it by name

ok.. that makes sense..

digging into the emlxs driver

and there's a lot of '#ifdef x86' that seems like it's unnecessary

got a link?

(also a few other head scratchers, like spawning a thread to asyncronously send a packet -- feels like a taskq would be better)

the FC drivers (and indeed the software) that came out of NWS are of a different standard

(sorry jmcp, if you're still here somewhere)

hrm.. i suppose links to my local opengrok instance are probably not helpful :)

well if the file and line number match they work :)

yeah, that doesn't make sense to me, wow

since i'm guessing we're unlikely to ever get any future source from emulex, it'd be nice to get rid of some of the ifdefs that'll never change

(e.g. I think we can safely assume MSI and MSI-X support)

yeah, this came in with the NWS merge

which probably means we have no actual memory of why

I suppose, thinking more like sommerfeld tends to from first principles, there exists the possibility that emlxs on sparc was excusively the sun-branded parts with FCode, and they're using the ifdef to imply that

but that's my only distant guessk

not quite following the discussions but .. wow (all those magic constants!).

basically trying to dig into the driver to see if there's anything that might be limiting throughput

but hitting several 'that's odd' type things

my first thought was to see if we're maybe limiting the amount of resources we use

(perhaps based on a time where 2MB was an exhorbinant amount of memory)

i was hoping for maybe some kstats that might track that, but while there are kstats, they don't track that

(it also seems to use it's own pooled allocator)

I'm not a very hardware person, but taking the comment at face value, I can't work out why you would ever do that, either.

well ISTR in the 32-bit x86 days there were some DMA limits that you didn't hit on sparc

but I _think_ those are mostly gone now on a 64-bit kernel

especially for most modern cards that don't have a small limit on what paddrs they can use for DMA

but wouldn't you have different dma attributes, rather than two distinct code paths that treat the SGL differently, etc?

is the sparc side breaking up the SGL on its own, and not letting the DDI do it, is that what it means?

i don't know (yet)