Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
once 64-bit plan 9 (in whatever guise) is stable, you might just as well use that for SSE. i did think about putting the 6c changes back into 8c, but there are still x86-32 systems that offer only 387s. mind you, with an SSE [subset] emulator to replace fp387.c, those systems might just as well use emulated SSE. i can't imagine people do much FP on them, especially using Plan 9. On 25 November 2011 23:39, erik quanstrom quans...@quanstro.net wrote: ideally, i'd like to be able to use sse with 8[acl].
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
Also, we are trying to make our changes in a way that they could help the stock distribution, which is, again, what I said would be better than doing them in incompatible ways. I understand this is going to be difficult, I don't expect anyone to take this on right now, but I still maintain that there ought to be a single Plan 9 distribution and that nix and 9front ought to be derivable from this. And Code Review ought to be at the core of it. As additional justification, I'd like to point out that the nix sources are alien to me and I don't have the space to install nix and run it so as to contribute to its development, whereas any changes to the original Plan 9 distribution affects my working environment directly, which makes it trivial to submit changes if I develop them. Maybe a middle ground would be to extract from Plan 9, nix and 9front all the code that is not platform specific (like the Go code, for example) and maintain that independently of the platforms. The divergent platforms could then be kept as small as possible. ++L
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
That's what I was saying. We are working in nix in such a way that we hope the code we are working on could be used by the stock Plan 9 in the future. So, it's a fork, but we are still trying to cooperate with everyone else. Branching seems to be a black hole, though: there is no easy way to bring forks into line with each other unless the divergences are few and very small. In my particular case, there is no way that I can progress from Plan 9 to nix, so there is no room for me to contribute to nix. Now, if we can isolate the portions of the Plan 9 distribution that can grow equally for all forks (9front, nix) from the, hopefully smaller, portions that define the different platforms, we will have a world in which contributions, mechanically, can be propagated everywhere. By making the different sections as small as possible, preferably actively trying to shrink them by propagating changes between them as frequently as possible, we may cause them to converge. But the keyword here is actively and demands the allocation of resources or, at minimum, intent that is absent in a competitive environment. ++L
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
A timely discussion before producing any code is usually more profitable. On 25 November 2011 08:06, Lucio De Re lu...@proxima.alt.za wrote: And Code Review ought to be at the core of it.
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
(I know Erik has adopted at least the BCM57xx driver for 9atom). I'm although it's in there, it doesn't work with the bcm57xx hardware i have. so cavet emptor. - erik
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
surely it only makes sense that when forks appear the knives come out. I guess this is part of the reason I follow 9fans so avidly :-) ++L
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
On Fri Nov 25 01:47:12 EST 2011, cinap_len...@gmx.de wrote: drivers should be pretty portable. there are more drastic changes like the eqlock function that touched many places. its basicly a normal qlock() that can error() out when the process gets a note or gets killed. ha! i've written this function independently a few times. and applied it to a few well-chosen places. i stopped short because i wondered if postdawn (e.g. after schedinit() is called), qlock() shouldn't always be an eqlock(). i see this problem most often with networking code. the the first reader is interruptable, but readers 2..n are not. i'd love to hear other opinions on how to solve this problem. - erik
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
On Fri, Nov 25, 2011 at 7:55 AM, erik quanstrom quans...@quanstro.net wrote: (I know Erik has adopted at least the BCM57xx driver for 9atom). I'm although it's in there, it doesn't work with the bcm57xx hardware i have. so cavet emptor. You might want to re-synch. Recent changes have caused the BCM5755 in my Thinkcentre M55 to start working. -sl
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
still not working; doesn't even reset.
i've taken a pass at cleaning up the code. the biggest change
is using style(6) formatting. also, coherence() is missing when
entering ring entries, since the posted write of the ring ptr can
pass the memory writes of the ring entry, from the perspective
of the pci root complex. and transmit wasn't careful enough
not to run into its head. (checking the chip isn't good enough.
you have to not run over your own unfreed bps.)
- erik/*
* Broadcom BCM57xx
* Not implemented:
* proper fatal error handling
* multiple rings
* QoS
* checksum offloading
*/
/* this driver needs some work, and probablly doesn't conform to style(6) */
#include u.h
#include ../port/lib.h
#include mem.h
#include dat.h
#include fns.h
#include io.h
#include ../port/error.h
#include ../port/netif.h
#include etherif.h
#define dprint(...) do{ if(debug)print(__VA_ARGS__); }while(0)
#define RbszROUNDUP(sizeof(Etherpkt)+4, 4)
#define Pciwaddrl(x)PCIWADDR(x)
#define Pciwaddrh(x)(sizeof(uintptr)4? (uvlong)PCIWADDR(x)32: 0)
typedef struct Ctlr Ctlr;
struct Ctlr {
Lock txlock, imlock;
Ctlr *next;
Pcidev *pdev;
ulong *nic, *status;
ulong *recvret, *recvprod, *sendr;
ulong port;
ulong recvreti, recvprodi, sendri, sendcleani;
Block **sends;
Block **rxs;
int active, duplex;
uintnobuf;
uintpartial;
uintrxerr;
uintqfull;
uintdmaerr;
};
enum {
RecvRetRingLen = 0x200,
RecvProdRingLen = 0x200,
SendRingLen = 0x200,
Reset = 10,
Enable = 11,
Attn = 12,
PowerControlStatus = 0x4C,
MiscHostCtl = 0x68,
ClearIntA = 10,
MaskPCIInt = 11,
IndirectAccessEnable = 17,
EnablePCIStateRegister = 14,
EnableClockControlRegister = 15,
TaggedStatus = 19,
Fwmbox = 0x0b50, /* magic value exchange */
Fwmagic = 0x4b657654,
DMARWControl = 0x6C,
DMAWatermarkMask = ~(719),
DMAWatermarkValue = 319,
MemoryWindow = 0x7C,
MemoryWindowData = 0x84,
SendRCB = 0x100,
RecvRetRCB = 0x200,
InterruptMailbox = 0x204,
RecvProdBDRingIndex = 0x26c,
RecvBDRetRingIndex = 0x284,
SendBDRingHostIndex = 0x304,
MACMode = 0x400,
MACPortMask = ~((13)|(12)),
MACPortGMII = 13,
MACPortMII = 12,
MACEnable = (123) | (122) | (121) | (1 15) | (1 14) |
(112) | (111),
MACHalfDuplex = 11,
MACEventStatus = 0x404,
MACEventEnable = 0x408,
MACAddress = 0x410,
EthernetRandomBackoff = 0x438,
ReceiveMTU = 0x43C,
MIComm = 0x44C,
MIStatus = 0x450,
MIMode = 0x454,
ReceiveMACMode = 0x468,
TransmitMACMode = 0x45C,
TransmitMACLengths = 0x464,
MACHash = 0x470,
ReceiveRules = 0x480,
ReceiveRulesConfiguration = 0x500,
LowWatermarkMaximum = 0x504,
LowWatermarkMaxMask = ~0x,
LowWatermarkMaxValue = 2,
SendDataInitiatorMode = 0xC00,
SendInitiatorConfiguration = 0x0C08,
SendStats = 10,
SendInitiatorMask = 0x0C0C,
SendDataCompletionMode = 0x1000,
SendBDSelectorMode = 0x1400,
SendBDInitiatorMode = 0x1800,
SendBDCompletionMode = 0x1C00,
ReceiveListPlacementMode = 0x2000,
ReceiveListPlacement = 0x2010,
ReceiveListPlacementConfiguration = 0x2014,
ReceiveStats = 10,
ReceiveListPlacementMask = 0x2018,
ReceiveDataBDInitiatorMode = 0x2400,
ReceiveBDHostAddr = 0x2450,
ReceiveBDFlags = 0x2458,
ReceiveBDNIC = 0x245C,
ReceiveDataCompletionMode = 0x2800,
ReceiveBDInitiatorMode = 0x2C00,
ReceiveBDRepl = 0x2C18,
ReceiveBDCompletionMode = 0x3000,
HostCoalescingMode = 0x3C00,
HostCoalescingRecvTicks = 0x3C08,
HostCoalescingSendTicks = 0x3C0C,
RecvMaxCoalescedFrames = 0x3C10,
SendMaxCoalescedFrames = 0x3C14,
RecvMaxCoalescedFramesInt = 0x3C20,
SendMaxCoalescedFramesInt = 0x3C24,
StatusBlockHostAddr = 0x3C38,
FlowAttention = 0x3C48,
MemArbiterMode = 0x4000,
BufferManMode = 0x4400,
MBUFLowWatermark = 0x4414,
MBUFHighWatermark = 0x4418,
ReadDMAMode = 0x4800,
ReadDMAStatus = 0x4804,
WriteDMAMode = 0x4C00,
WriteDMAStatus = 0x4C04,
RISCState = 0x5004,
FTQReset = 0x5C00,
MSIMode = 0x6000,
ModeControl = 0x6800,
ByteWordSwap = (14)|(15)|(12),//|(11),
HostStackUp = 116,
HostSendBDs = 117,
InterruptOnMAC =
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
re: etherbcm.c thanks, Again it will have to wait till monday for me to try. BTW I'am not sure if I emphasised enough how grateful I am for all your patient work in getting SSE working. Its great to make progress on this, though the performance of opera + linuxemu + equis (fgb's X11 server) is not great. Its enough to drag my 3.5Ghz P4 to its knees just browsing around! Having said this there avenues for optimisation, but I need to measure and not guuess (no matter how tempting :-) where the problems lie. -Steve
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
BTW I'am not sure if I emphasised enough how grateful I am for all your patient work in getting SSE working. really it's no problem. it's something that i'd worked on before, and had to leave behind. ideally, i'd like to be able to use sse with 8[acl]. but that means that i (a) have to figure out how to make /proc/$pid/regs work with sse/nonsse or (b) need to come up with a new arch that's a lot like 8/386/pc. perhaps 4/p6/p6. p6 was the first sse2-implementing arch. - erik
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
fixed for my hw. the really key bit was setting the endianness
properly. this may have been set up by your pxe hardware or bios,
if your bcm chip was built-in.
i've updated 9atom with this driver.
- erik/*
* Broadcom BCM57xx
* Not implemented:
* proper fatal error handling
* multiple rings
* QoS
* checksum offloading
*/
/* this driver needs some work, and probablly doesn't conform to style(6) */
#include u.h
#include ../port/lib.h
#include mem.h
#include dat.h
#include fns.h
#include io.h
#include ../port/error.h
#include ../port/netif.h
#include etherif.h
#define dprint(...) do{ if(debug)print(__VA_ARGS__); }while(0)
#define RbszROUNDUP(sizeof(Etherpkt)+4, 4)
#define Pciwaddrl(x)PCIWADDR(x)
#define Pciwaddrh(x)(sizeof(uintptr)4? (uvlong)PCIWADDR(x)32: 0)
typedef struct Ctlr Ctlr;
struct Ctlr {
Lock txlock, imlock;
Ctlr *next;
Pcidev *pdev;
ulong *nic, *status;
ulong *recvret, *recvprod, *sendr;
ulong port;
ulong recvreti, recvprodi, sendri, sendcleani;
Block **sends;
Block **rxs;
int active, duplex;
uintnobuf;
uintpartial;
uintrxerr;
uintqfull;
uintdmaerr;
};
enum {
RecvRetRingLen = 0x200,
RecvProdRingLen = 0x200,
SendRingLen = 0x200,
Reset = 10,
Enable = 11,
Attn = 12,
PowerControlStatus = 0x4C,
MiscHostCtl = 0x68,
TaggedStatus= 19,
IndirectAccessEnable= 17,
EnableClockControl = 15,
EnablePCIStateRegister = 14,
WordSwap= 13,
ByteSwap= 12,
MaskPCIInt = 11,
ClearIntA = 10,
Fwmbox = 0x0b50, /* magic value exchange */
Fwmagic = 0x4b657654,
DMARWControl = 0x6C,
DMAWatermarkMask = ~(719),
DMAWatermarkValue = 319,
MemoryWindow = 0x7C,
MemoryWindowData = 0x84,
SendRCB = 0x100,
RecvRetRCB = 0x200,
InterruptMailbox = 0x204,
RecvProdBDRingIndex = 0x26c,
RecvBDRetRingIndex = 0x284,
SendBDRingHostIndex = 0x304,
MACMode = 0x400,
MACPortMask = ~((13)|(12)),
MACPortGMII = 13,
MACPortMII = 12,
MACEnable = (123) | (122) | (121) | (1 15) | (1 14) |
(112) | (111),
MACHalfDuplex = 11,
MACEventStatus = 0x404,
MACEventEnable = 0x408,
MACAddress = 0x410,
EthernetRandomBackoff = 0x438,
ReceiveMTU = 0x43C,
MIComm = 0x44C,
MIStatus = 0x450,
MIMode = 0x454,
ReceiveMACMode = 0x468,
TransmitMACMode = 0x45C,
TransmitMACLengths = 0x464,
MACHash = 0x470,
ReceiveRules = 0x480,
ReceiveRulesConfiguration = 0x500,
LowWatermarkMaximum = 0x504,
LowWatermarkMaxMask = ~0x,
LowWatermarkMaxValue = 2,
SendDataInitiatorMode = 0xC00,
SendInitiatorConfiguration = 0x0C08,
SendStats = 10,
SendInitiatorMask = 0x0C0C,
SendDataCompletionMode = 0x1000,
SendBDSelectorMode = 0x1400,
SendBDInitiatorMode = 0x1800,
SendBDCompletionMode = 0x1C00,
ReceiveListPlacementMode = 0x2000,
ReceiveListPlacement = 0x2010,
ReceiveListPlacementConfiguration = 0x2014,
ReceiveStats = 10,
ReceiveListPlacementMask = 0x2018,
ReceiveDataBDInitiatorMode = 0x2400,
ReceiveBDHostAddr = 0x2450,
ReceiveBDFlags = 0x2458,
ReceiveBDNIC = 0x245C,
ReceiveDataCompletionMode = 0x2800,
ReceiveBDInitiatorMode = 0x2C00,
ReceiveBDRepl = 0x2C18,
ReceiveBDCompletionMode = 0x3000,
HostCoalescingMode = 0x3C00,
HostCoalescingRecvTicks = 0x3C08,
HostCoalescingSendTicks = 0x3C0C,
RecvMaxCoalescedFrames = 0x3C10,
SendMaxCoalescedFrames = 0x3C14,
RecvMaxCoalescedFramesInt = 0x3C20,
SendMaxCoalescedFramesInt = 0x3C24,
StatusBlockHostAddr = 0x3C38,
FlowAttention = 0x3C48,
MemArbiterMode = 0x4000,
BufferManMode = 0x4400,
MBUFLowWatermark = 0x4414,
MBUFHighWatermark = 0x4418,
ReadDMAMode = 0x4800,
ReadDMAStatus = 0x4804,
WriteDMAMode = 0x4C00,
WriteDMAStatus = 0x4C04,
RISCState = 0x5004,
FTQReset = 0x5C00,
MSIMode = 0x6000,
ModeControl = 0x6800,
ByteWordSwap = (14)|(15)|(12),//|(11),
HostStackUp = 116,
HostSendBDs = 117,
InterruptOnMAC = 126,
MiscConfiguration = 0x6804,
CoreClockBlocksReset = 10,
GPHYPowerDownOverride = 126,
DisableGRCResetOnPCIE =
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
A handful of device drivers have been written from scratch. Some devices started working when their PCI IDs were added to existing drivers. A bit like pulling teeth, isn't it? It is natural to become defensive of one's efforts, but that also leads to categorising those against whom defenses are erected as the enemy; how else does one justify them? Plan 9 is _not_ 9front's enemy except in the imagination, let's not make it so in real life. My vote, in this world of democratic revolution, is to persuade nemo, forsyth, cinap, jim and geoff to be a starting core of moderators for a Code Review of Plan 9. Takers? ++L
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
theres a new miniport originaly based on the ac97 driver for the audio devices. sb16 driver was rewritten mainly to get interrupt free output in emulators like qemu and bochs. required minimal changes to the legacy dma controller code. hda driver was written from scratch. all audio drivers support controlling the output buffer delay. there where some changes to usb hci drivers to support controlling the buffer delay on isochronous endpoints. some big changes to the userspace usb parts. instead of providing a special framework to write usb userspace drivers that all run in the usbd host process to provide a single service, we split them into separate programs again that are free to choose whatever they want. usb audio driver rewritten from scratch. (very minimalistic, but supports delay control) the usb storage driver got sd partition support. hotplugging usb devices works differently. usb drivers get started by a rc script. thers a new devshr device that acts as a global mount table (its like /srv just also having a mount part). with this, usb filesystems just register ther 9p channels to devshr and it becomes visible on /dev or /shr. usb storage devices get auto mounted when they contain a fat partition. theres usb-ptp camera support, behaves identical to usb mass storage case. fixed rtl8169 as it used to stop receiving packets from time to time causing huge delays. bcm ethernet was written from scratch. keyboard input works differently. kernel exports a #b/scancode, #b/leds files, #c/cons returns 0 bytes on read. theres no input processing (uart, kbd) in the kernel anymore. kbdfs does all the input processing and exports the usual files plus a new /dev/kbd wich is also multiplexed by rio and used by programs like games/doom to get keyboard input. using eriks sata and ide drivers with some adaptions. pci ids, enabling dma by default, fix some problems with dma+atapi on qemu/bochs. many vga changes. aux/vga now uses devpnp to enumerate the pci devices. vesa screenblanking. amd geode driver support. utf-8 support for cga. no #P/realmode anymore. no 16bit code in kernel, e820 scan done by bootloader. thats all i can remember for hardware related stuff right now. -- cinap
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
theres a new miniport originaly based on the ac97 driver for the audio devices. sb16 driver was rewritten mainly to get interrupt free output [... snip ...] Yeow! no #P/realmode anymore. no 16bit code in kernel, e820 scan done by bootloader. thats all i can remember for hardware related stuff right now. ... and a pretty good memory, too! Sounds like irreconcilable differences, does that mean divorce is inevitable? :-) :-) :-) ++L
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
drivers should be pretty portable. there are more drastic changes like the eqlock function that touched many places. its basicly a normal qlock() that can error() out when the process gets a note or gets killed. -- cinap
Re: [9fans] Forks of Plan 9 (Was: 9vx instability)
I'd like to say here that I'm sorry if my mail in this thread did hurt any feelings. That was not my aim, again. I know all of us keep a local copy in one way or another, but I'd like to suggest that all of us keep on sending patches and code to bell labs; that's the least we can do, considering the excellent code base those guys gave us in the first place. Regarding the codereview suggestion, nix is already under code review, and we intend it to be not just a research system, but also a kernel that could be used as a 64bits plan 9 system. All of you are more than welcome to send CLs there. Also, we are trying to make our changes in a way that they could help the stock distribution, which is, again, what I said would be better than doing them in incompatible ways. cheers
