This comes in a new thread because my ML membership was somehow hosed coreboot-side, so I have no mail to reply to.
I have until now ignored this code of conduct. There's been talk about how people feel unwelcome in _other_ projects, about how _other_ projects (fill in the blank). What there hasn't been any talk of, however, is any instance where this has been a problem in _our_ community.
coreboot _is_ a hard thing. You _do_ need a _hard_skin_ to do coreboot. That's just the nature of our work. That is not because of our attitude; hardware is crap. People get annoyed at it. They bash it and vent out. It's normal. There's absolutely no point in burdening our developers with a generic code of of conduct.
I don't know how much time Marc actually spends on IRC, but we have been great at policing ourselves. Pretending someone else's problem as our own is just silly. The fact is, the problem Marc pointed out, and the problems he tries to solve with this code of conduct are non-present in our community. I've seen more helpful people jumping to aid than in any other project. I've seen more good will and personal time invested to help others than in any other project.
I've only seen Peter give new guys the RTFW, RTFS, or STFW, and those have been well deserved by the person receiving them. Are we going to start taking action against some of our most experienced and valuable developers because they didn't waste their personal time doing someone else's homework?
There's a phenomenon of "Oh, I saw this thing here, so let's implement it irrespective of whether or not it's actually relevant". I call that liberal bullshit. That's exactly what this is.
This code of conduct is an insult to our hard work over the years, and an insult to our friendly nature and countless personal hours spent helping others. When you've put up this code of conduct, you've basically said "our community is not capable of bettering itself by peer action and common sense, so we need to enforce it". It degrades every person who has ever contributed, and degrades the community as a whole. It's a degrading document that has no place.
Alex
On 08.02.2015 19:07, Alexandru Gagniuc wrote:
I have until now ignored this code of conduct. There's been talk about how people feel unwelcome in _other_ projects, about how _other_ projects (fill in the blank). What there hasn't been any talk of, however, is any instance where this has been a problem in _our_ community.
On January 16, 2015, Marc Jones wrote in a coreboot.org blog post:
While most developers dont experience something as terrible as the harassment that happened in the context of Gamergate or other terrible behavior documented at technical and open source conferences the last several years, it does indicate that there is a problem in our open source communities.
I think the sentence above pretty much describes what went wrong in the process creating the coreboot code of conduct. Using gamergate (Disclaimer: I'm not a gamer, I prefer real cardboard puzzles) as an indicator that there is a problem in our open source communities is a logical fallacy (majority of game market share is not open source). Using terrible behaviour documented at technical conferences as an indicator that there is a problem in our open source communities is a logical fallacy (majority of tech market share is not open source). However, using terrible behaviour documented at open source conferences as an indicator that there is a problem in our open source communities is logically correct. Now there are some open source communities which reportedly have more problems and some which reportedly have less or no problems. It would be very interesting to see how they differ, and then check how this can be applied to us.
Right now prescribing a code of conduct is hip and trendy because everyone does it. It also seems to be necessary in many places.
Marc wrote: "it's a part of growing up", but in the real-life community I was brought up (i.e. the city where I lived), a code of conduct was considered a sign that something had broken down before and needed patching up. See school rules for an example. Consider a relationship: If there is a code of conduct in a relationship, it's probably about who may see or interact with the joint children at any given time.
On 08.02.2015 19:07, Alexandru Gagniuc wrote:
There's a phenomenon of "Oh, I saw this thing here, so let's implement it irrespective of whether or not it's actually relevant". I call that liberal bullshit. That's exactly what this is.
I don't know about liberals in the USA, but in the EU, this would be a conservative position. Then again, the definitions of liberal and conservative seem to be completely different in the US vs EU.
On 08.02.2015 19:07, Alexandru Gagniuc wrote:
This code of conduct is an insult to our hard work over the years, and an insult to our friendly nature and countless personal hours spent helping others. When you've put up this code of conduct, you've basically said "our community is not capable of bettering itself by peer action and common sense, so we need to enforce it". It degrades every person who has ever contributed, and degrades the community as a whole. It's a degrading document that has no place.
On January 16, 2015, Marc Jones wrote in a coreboot.org blog post:
We cant lose valuable contributors because they felt uncomfortable or unwanted.
Alexandru, since you are a valuable contributor and feel uncomfortable with the to-be-established Code of Conduct in its current form, those who created the Code of Conduct surely will want to make sure not to lose you. I trust them to come up with a solution for this.
Regards, Carl-Daniel
Greetings!
I'm looking to adjust the amount of system memory allocated to the GPU on panther (Haswell mobile), since certain applications (eg, Steam) report a suboptimal amount of GPU memory. lspci reports the following:
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation Haswell-ULT Integrated Graphics Controller Flags: bus master, fast devsel, latency 0, IRQ 43 Memory at e0000000 (64-bit, non-prefetchable) [size=4M] Memory at d0000000 (64-bit, prefetchable) [size=256M] I/O ports at 3000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915
Looking at src/northbridge/intel/haswell/early_init.c, the 256M appears to correlate to the MSAC register, and going by Intel's datasheet, setting the MSAC to 0x6 (from the current value of 0x2) should increase the allocation to 512MB, yet doing so appears to have no affect (at least as far as lspci is concerned).
I also looked at the GMS portion of the GGC register, which is currently set to 32MB, but changing it, either in conjunction with or separately from MSAC, has no discernible effect either.
Obviously there's something else I'm missing, so would appreciate any help.
thanks, Matt
On Mon, Feb 9, 2015 at 10:49 PM, Matt DeVillier matt.devillier@gmail.com wrote:
Greetings!
I'm looking to adjust the amount of system memory allocated to the GPU on panther (Haswell mobile), since certain applications (eg, Steam) report a suboptimal amount of GPU memory. lspci reports the following:
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation Haswell-ULT Integrated Graphics Controller Flags: bus master, fast devsel, latency 0, IRQ 43 Memory at e0000000 (64-bit, non-prefetchable) [size=4M] Memory at d0000000 (64-bit, prefetchable) [size=256M] I/O ports at 3000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915
Looking at src/northbridge/intel/haswell/early_init.c, the 256M appears to correlate to the MSAC register, and going by Intel's datasheet, setting the MSAC to 0x6 (from the current value of 0x2) should increase the allocation to 512MB, yet doing so appears to have no affect (at least as far as lspci is concerned).
I also looked at the GMS portion of the GGC register, which is currently set to 32MB, but changing it, either in conjunction with or separately from MSAC, has no discernible effect either.
Obviously there's something else I'm missing, so would appreciate any help.
The MSAC is the aperture window while the GGC is the stolen memory for the graphics. The aperture just gives a contiguous window into memory mapped by GPU (which could be the stolen memory). The stolen memory for graphics really just makes displaying things in firmware easier since there's a set aside piece of memory to use as a framebuffer.
I'm not familiar with Steam's complaints about suboptimal GPU memory (or any other apps). Can you quote the complaint so further research can be done into what it's actually looking at.
All that said, I looked into the reference code you're running. It sets a fixed 256MiB aperture. You should be able to change MSAC after the memory training is done in romstage. You can confirm this by keeping your 0x6 value in early_init.c and reading that register back after memory init has been done. Additionally, the 32MiB of stolen memory is also fixed in the MRC, but you can't just change that after the fact because that affects the physical address space directly.
Hope that helps.
-Aaron
-
Aaron Durbin -
Alexandru Gagniuc -
Carl-Daniel Hailfinger -
Matt DeVillier