Re: [osol-discuss] No network/Internet
On 10/16/10 01:13 PM, Jürgen Keil wrote: j...@opensolaris:~$ ifconfig nge0 ifconfig: status: SIOCGLIFFLAGS: nge0: no such interface nVidia MCP61 should work in build 73 or newer: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6497473 Is the nge driver matter here? The original message said: Foxconn M61PMV M.B.; AMD Phenom X3 CPU @ 2.1GHz GeForce 6150SE 128MB; nForce 430 Chipset. -- And finally, this is my network adapter: BroadCom AC131 (MCP61 nForce 4 LAN). According to the Foxconn web page the NIC is Broadcom AC131: http://www.foxconnchannel.com/product/Motherboards/detail_overview.aspx?id=en-us412 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
While it doesn't help existing binaries, would it be possible to for new 32-bit binaries persuade the linker to issue a redundant (same as ABI) PT_SUNWSTACK header? That I suppose elfedit _would_ be able to change after-the-fact. I gather one could do it indirectly, by linking with -M /usr/lib/ld/map.noexstk and then restoring stack execute permission with elfedit (so that someone could take it away again later if they wanted to), but that's clearly silly. [Update] I just tried back on SXCE snv_97 (still haven't updated) with a map file containing stack = STACK ?RWX; and that appeared to work - the header was generated with the requested permissions. So it ought to be rather easy to change the linker to just generate the header explicitly by default. The point would be if inserting the seemingly redundant header could happen by default, which would allow someone to correct the developer's omission of turning off stack execute permission when linking. OTOH, I suppose elfedit would mess with signed executables (not that they're that big a deal until enforcement is generally available). And of course, whenever reasonably expected calculations involving future times would pass the Jan 19 03:14:07 2038 mark, the existing 32-bit ABI would be broken anyway. (to figure out something involving a 30 year mortgage, that would already have been a problem for a couple of years now...) Too bad larger time_t wasn't part of largefile support. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] No network/Internet
j...@opensolaris:~$ ifconfig nge0 ifconfig: status: SIOCGLIFFLAGS: nge0: no such interface nVidia MCP61 should work in build 73 or newer: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6497473 Is the nge driver matter here? The original message said: ... And finally, this is my network adapter: BroadCom AC131 (MCP61 nForce 4 LAN). According to the Foxconn web page the NIC is Broadcom AC131: http://www.foxconnchannel.com/product/Motherboards/detail_overview.aspx?id=en-us412 As far as I understand it, the Broadcom AC131 is the PHY chip attached at the nVidia MCP61 network controller. The nVidia MCP61 ethernet controller should be handled by the Solaris nge driver. The device driver utility is reporting that the nge driver will be used with the nVidia MCP61 device: http://www.opensolaris.org/jive/thread.jspa?messageID=502914#502914 Maybe the nge driver needs some special code to handle the Broadcom AC131 PHY ? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
On 10/17/10 4:58 AM, Richard L. Hamilton wrote: While it doesn't help existing binaries, would it be possible to for new 32-bit binaries persuade the linker to issue a redundant (same as ABI) PT_SUNWSTACK header? That I suppose elfedit _would_ be able to change after-the-fact. I gather one could do it indirectly, by linking with -M /usr/lib/ld/map.noexstk and then restoring stack execute permission with elfedit (so that someone could take it away again later if they wanted to), but that's clearly silly. [Update] I just tried back on SXCE snv_97 (still haven't updated) with a map file containing stack = STACK ?RWX; and that appeared to work - the header was generated with the requested permissions. So it ought to be rather easy to change the linker to just generate the header explicitly by default. The point would be if inserting the seemingly redundant header could happen by default, which would allow someone to correct the developer's omission of turning off stack execute permission when linking. OTOH, I suppose elfedit would mess with signed executables (not that they're that big a deal until enforcement is generally available). And of course, whenever reasonably expected calculations involving future times would pass the Jan 19 03:14:07 2038 mark, the existing 32-bit ABI would be broken anyway. (to figure out something involving a 30 year mortgage, that would already have been a problem for a couple of years now...) Too bad larger time_t wasn't part of largefile support. I've had the same thought about having ld always generate a PT_SUNWSTACK, and even sent some internal email yesterday proposing it to my fellow linker alien. It's actually simpler than what we do now, since we'd just remove the code that checks the header flags against the ABI defaults before issuing the header. It seems reasonable to me, and we'll see what others think. I don't view the fact that elfedit breaks the signature of an object as a problem. If we deliver an object with an executable stack, and it's modified in the field, that's the sort of thing you'd want to detect. You can certainly cause ld to inject a redundant header yourself, using a mapfile. However, as you pointed out earlier in this thread, it's a rare application that really needs an executable stack. So if you're aware enough of the issue to be able to arrange for a PT_SUNWSTACK to be added to the object with a mapfile, you might as well and make it non-executable, rather than the redundant one. The redundant header is only really helpful if it's always put there by ld as a default action. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] No network/Internet
On 10/17/10 08:50 AM, Jürgen Keil wrote: As far as I understand it, the Broadcom AC131 is the PHY chip attached at the nVidia MCP61 network controller. The nVidia MCP61 ethernet controller should be handled by the Solaris nge driver. The device driver utility is reporting that the nge driver will be used with the nVidia MCP61 device: http://www.opensolaris.org/jive/thread.jspa?messageID=502914#502914 Maybe the nge driver needs some special code to handle the Broadcom AC131 PHY ? I can't find anything on the Broadcom site about AC131, but if it is just a PHY connected to the nForce MAC then the nge code is pretty generic. On one motherboard I've seen an issue with nge driver is bringing the PHY out of low power mode after warm booted from another OS. Since there isn't device specific code to handle this, sometimes a cold boot is needed to put the PHY in a state where it works with the nForce MAC. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
