08:25:29 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. 08:26:55 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 08:28:36 well, you can test that hypothesis by running "update_drv -a -i pciex10ec,8161 rge" 08:46:32 Woodstock, great :) thanks. rge recognized the card (again) and it is seen in dladm show-phys 08:51:50 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 :) 08:52:02 Of course, because network card is not initialized, because it were not attached to rge on boot 08:57:21 Obviously I would need also some functionality testing, e.g. making the change permanent in current install for testing 09:20:04 it's permanent in your BE after you ran update_drv 09:25:13 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. 09:30:20 ok, on SmartOS this won't persist, of course :) 10:35:19 if it appears to work, tests are good, then we can commit the change to gate and smartos will get it from there. 15:00:55 hrm.. https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/fibre-channel/fca/emlxs/emlxs_fc.h#L737-L934 -- couldn't those be replaced with a call to ddi_fls() ? 15:02:21 (or maybe coupled with a couple of statements to clamp the result 15:12:39 hrm.. i don't suppose any sun alumni might know what 'tigershark' might be referring to? 16:08:33 this is odd.. panic in tem because the STREAMS queue seems wrong 16:08:45 it's showing a part of the iphelper module 18:49:11 think tigershark is an FC adaptor 18:49:19 rather than anying upstream of one 18:49:26 but that's from 3 bugs referring to it by name 18:51:09 ok.. that makes sense.. 18:51:16 digging into the emlxs driver 18:51:44 and there's a lot of '#ifdef x86' that seems like it's unnecessary 18:52:04 got a link? 18:52:52 (also a few other head scratchers, like spawning a thread to asyncronously send a packet -- feels like a taskq would be better) 18:53:35 the FC drivers (and indeed the software) that came out of NWS are of a different standard 18:53:43 (sorry jmcp, if you're still here somewhere) 18:56:03 hrm.. i suppose links to my local opengrok instance are probably not helpful :) 18:56:22 well if the file and line number match they work :) 18:57:25 https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/io/fibre-channel/fca/emlxs/emlxs_solaris.c#L7214-L7233 18:59:53 yeah, that doesn't make sense to me, wow 19:00:16 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 19:00:29 (e.g. I think we can safely assume MSI and MSI-X support) 19:01:44 yeah, this came in with the NWS merge 19:02:00 which probably means we have no actual memory of why 19:03:07 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 19:03:46 but that's my only distant guessk 19:08:51 not quite following the discussions but .. wow (all those magic constants!). 19:09:47 basically trying to dig into the driver to see if there's anything that might be limiting throughput 19:09:58 but hitting several 'that's odd' type things 19:11:03 my first thought was to see if we're maybe limiting the amount of resources we use 19:11:31 (perhaps based on a time where 2MB was an exhorbinant amount of memory) 19:11:55 i was hoping for maybe some kstats that might track that, but while there are kstats, they don't track that 19:12:14 (it also seems to use it's own pooled allocator) 19:13:15 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. 19:14:14 well ISTR in the 32-bit x86 days there were some DMA limits that you didn't hit on sparc 19:14:26 but I _think_ those are mostly gone now on a 64-bit kernel 19:15:04 especially for most modern cards that don't have a small limit on what paddrs they can use for DMA 19:15:20 but wouldn't you have different dma attributes, rather than two distinct code paths that treat the SGL differently, etc? 19:16:16 is the sparc side breaking up the SGL on its own, and not letting the DDI do it, is that what it means? 19:16:35 i don't know (yet)