Re: CVS commit: src/sys/arch/sparc64/dev
Hi Tobias, > If you're interested there is an older version[1] of envctrl in the > Attic that might be relevant to use for reference. It supported fan > speed controls on E450. IIRC I got some of the magic constants from > OpenSolaris. Sadly I don't own an E450 any more. > > [1] > cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/arch/sparc64/dev/Attic/envctrl.c?rev=1.11=text/plain_with_tag=MAIN Thank you - that's useful information! Related to the magic offsets, I noticed that the value read from the sensor was always lower than the value written. However, it doesn't appear to be a constant difference (I see about 15 for most values, but only 5 for the minimum). I think that it's OK to keep the higher value - it'll mean that we run the fans slightly faster. The CPU temperature on my E250 doesn't reach the minimum threshold where the fan speed actually increases, so I don't think that this will have any impact. The GPIO values there helps to see what values I should be checking for too. It would be good to merge this with the current code, but I only have an E250 to test on, so I'll need to find a volunteer. Regards, Julian
Re: CVS commit: src/sys/arch/sparc64/dev
On Sat, 24 Oct 2020 15:16:39 + Julian Coleman wrote: > Module Name: src > Committed By: jdc > Date: Sat Oct 24 15:16:39 UTC 2020 > > Modified Files: > src/sys/arch/sparc64/dev: pcf8591_envctrl.c > > Log Message: > Add support for automatically changing the CPU fan speed on the E250 in a > similar way to the SB1000/SB2000. > The fan control information was determined by experiment, as it's only > partially available in OFW. > Hardcode the missing information for E250 fan control into the driver > (it should be possible to support the E450 in future too). If you're interested there is an older version[1] of envctrl in the Attic that might be relevant to use for reference. It supported fan speed controls on E450. IIRC I got some of the magic constants from OpenSolaris. Sadly I don't own an E450 any more. [1] cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/arch/sparc64/dev/Attic/envctrl.c?rev=1.11=text/plain_with_tag=MAIN
re: CVS commit: src/sys/arch/sparc64/dev
Module Name: src Committed By:nakayama Date:Sat Feb 13 11:55:48 UTC 2010 Modified Files: src/sys/arch/sparc64/dev: schizo.c schizoreg.h Log Message: Make 32-bit kernels compilable. thanks! i guess i never tried that. :) .mrg.
Re: CVS commit: src/sys/arch/sparc64/dev
matthew green m...@eterna.com.au wrote Module Name: src Committed By: nakayama Date: Mon Dec 7 11:14:27 UTC 2009 Modified Files: src/sys/arch/sparc64/dev: iommu.c Log Message: Avoid use of iommu_dvmamap_unload in error path. It is too expensive since it contains data cache flushing. Some driver (tlp(4) with DM9201 on Netra X1) can only handle one DMA segment, so it was called frequently. + /* How can this fail? And if it does what can we do? */ + err = extent_free(is-is_dvmamap, map-_dm_dvmastart, sgsize, + EX_NOWAIT); this can fail almost any time. it happens when there is no free memory and to free a chunk would require to split a current extent range into two. Ah, OK. I added the warning printf as well as what we do in iommu_dvmamap_unload. -- Takeshi Nakayama
