I think you could contact Enlightenment port maintainer
enlightenm...@freebsd.org, to ask makefile (and maybe sources) patching
according to FreeBSD conventions.
Hope you will solve the principal issue.
Peter
On 03/24/2016 13:42, Eric McCorkle wrote:
>> On Mar 24, 2016, at 00:50, Simon Lees w
> On Mar 24, 2016, at 00:50, Simon Lees wrote:
>
>
>
>> On 03/24/2016 03:09 PM, Carsten Haitzler (The Rasterman) wrote:
>> On Wed, 23 Mar 2016 19:15:38 -0400 Eric McCorkle said:
>>
>>> Ok, I cracked it.
>>>
>>> modules/cpufreq/e_mod_main.c
>>>
>>> In _cpufreq_face_update_available
>>>
>>>
Thanks.
This still seems to be an issue even with the suid bit working though. When I
enabled it on that partition, the program still reports "PStates not supported
on FreeBSD" and you end up with zero frequencies.
Also, fwiw, the expectation on FreeBSD is that powerd does all the frequency
ad
On 03/24/2016 03:09 PM, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 23 Mar 2016 19:15:38 -0400 Eric McCorkle said:
>
>> Ok, I cracked it.
>>
>> modules/cpufreq/e_mod_main.c
>>
>> In _cpufreq_face_update_available
>>
>> If count is 0, then you get an integer underflow and end up passing a
On Wed, 23 Mar 2016 19:15:38 -0400 Eric McCorkle said:
> Ok, I cracked it.
>
> modules/cpufreq/e_mod_main.c
>
> In _cpufreq_face_update_available
>
> If count is 0, then you get an integer underflow and end up passing a huge
> number to malloc. The code probably ought to check for 0 and do n
On Wed, 23 Mar 2016 19:15:38 -0400 Eric McCorkle said:
reading that code... the cpufreq module has ZERO frequencies supported then ...
your cpu has no frequencies... how interesting. :)
> Ok, I cracked it.
>
> modules/cpufreq/e_mod_main.c
>
> In _cpufreq_face_update_available
>
> If count is
On Wed, 23 Mar 2016 00:37:11 -0400 Eric McCorkle said:
> I actually got a good clue from the gdb suggestion. Stack trace looks like
> this (typing on a phone):
>
> e_modapi_save
> e_gadcon_provider_register
> e_gadcon_client_visible
> ecore_idler_del
> ecore_event_current_event_get
> ecore_main
Ok. I've confirmed that my theory was correct, but now I'm seeing the issue
described here: https://phab.enlightenment.org/T3097
I'll record all this on the bug report.
> On Mar 23, 2016, at 19:19, Simon Lees wrote:
>
>
>
>> On 03/24/2016 09:45 AM, Eric McCorkle wrote:
>> Ok, I cracked it.
On 03/24/2016 09:45 AM, Eric McCorkle wrote:
> Ok, I cracked it.
>
> modules/cpufreq/e_mod_main.c
>
> In _cpufreq_face_update_available
>
> If count is 0, then you get an integer underflow and end up passing a huge
> number to malloc. The code probably ought to check for 0 and do nothing in
Ok, I cracked it.
modules/cpufreq/e_mod_main.c
In _cpufreq_face_update_available
If count is 0, then you get an integer underflow and end up passing a huge
number to malloc. The code probably ought to check for 0 and do nothing in
that case.
It looks like there is a little suid program tha
To build FreeBSD port with debug symbols:
# make WITH_DEBUG=yes
That's how I proceeded to get detailed backtrace for phab ticket.
Peter
On 03/23/2016 19:16, Eric McCorkle wrote:
> I couldn't seem to track down where the allocation is happening there. I
> also couldn't get the freebsd port b
I couldn't seem to track down where the allocation is happening there. I also
couldn't get the freebsd port build to do debug builds.
I'm going to try good old printf debugging tonight to get to the bottom of it.
On March 23, 2016 11:50:14 AM EDT, Miguel C wrote:
>On Wed, Mar 23, 2016 at 1:1
On Wed, Mar 23, 2016 at 1:14 PM, Eric McCorkle wrote:
> A possible root cause: ZFS allows for noexec and nosuid options on file
> systems. I believe the freebsd installer sets them by default, so if
> you're storing executables in places other than bin/ directories, that
> could be part of the p
A possible root cause: ZFS allows for noexec and nosuid options on file
systems. I believe the freebsd installer sets them by default, so if you're
storing executables in places other than bin/ directories, that could be part
of the problem.
On March 23, 2016 4:21:07 AM EDT, Quelrond wrote:
Hi,
Just to inform you that the issue I've create some weeks ago
https://phab.enlightenment.org/T3097 was observed on a system with ZFS
root too.
Peter
On 03/23/2016 05:42, Miguel C wrote:
> are you using zfs on root? I've seen reports of this issue if using zfs and
> I got the same issue on m
Indeed I am.
On March 23, 2016 12:42:15 AM EDT, Miguel C wrote:
>are you using zfs on root? I've seen reports of this issue if using zfs
>and
>I got the same issue on my laptop but haven't tried gdb or any further
>debugging but just curios if it's related
>
>On Wednesday, March 23, 2016, Eric Mc
are you using zfs on root? I've seen reports of this issue if using zfs and
I got the same issue on my laptop but haven't tried gdb or any further
debugging but just curios if it's related
On Wednesday, March 23, 2016, Eric McCorkle wrote:
> I actually got a good clue from the gdb suggestion. S
I actually got a good clue from the gdb suggestion. Stack trace looks like
this (typing on a phone):
e_modapi_save
e_gadcon_provider_register
e_gadcon_client_visible
ecore_idler_del
ecore_event_current_event_get
ecore_main_loop_iterate
ecore_main_loop_begin
main
Above that is what basically com
On Tue, 22 Mar 2016 08:50:21 -0400 Eric McCorkle said:
> Hi folks,
>
> I'm in the process of setting up a new FreeBSD system. I've used
> enlightenment on FreeBSD in the past (0.17-0.19) and it's worked alright.
> However, this time around, I seem to be running into some issues.
>
> I'm testin
Hi folks,
I'm in the process of setting up a new FreeBSD system. I've used enlightenment
on FreeBSD in the past (0.17-0.19) and it's worked alright. However, this time
around, I seem to be running into some issues.
I'm testing with startx, and the load screen freezes after displaying "loading
20 matches
Mail list logo
