Re: [9fans] APL
Lyndon, Did you get it to run on OpenBSD? J. On Wed, Feb 24, 2021 at 5:49 AM Steffen Nurpmeso wrote: > Lyndon Nerenberg (VE7TFX/VE6BBM) wrote in > <0903a00d50966...@orthanc.ca>: > |Steffen Nurpmeso writes: > |> It can even be as small as > |> > |> #?0|kent:unix-hist$ du -sh . > |> 179M. > |> > |> when not including all the new FreeBSD things (for which i at > |> least track the FreeBSD git repository directly): > > Traffic size is a real issue for me. > (As is quality of the rtw88 driver of Linux 5.10.*, as is the fact > that git i think still cannot resume failed clones. I anyway had > lots and lots of trouble and yes grief due to this, here.) > > |Okay, so what's the magic incantation to clone just that subset > |of branches? git-clone(1) is not helpful ... > > Backward compatible for "the one real git" is > > $ cd DIR; git init > $ git remote add origin -t BRANCH1 -t BRANCH2 -t 'release/*' URL > $ git fetch -v > > Or git init and then copy the snippet :) > (Mind you, just a few weeks ago on FreeBSD it turned out that > i should re-learn git from scratch. I turned to it around > 2010/11, wrote some scripts and aliases, and unless they break, > for example due to rev-list reverting output in about 2013, i have > a very basic way of doing, lots of update-ref and such, for > example.) > > And sorry for the late reply, after weeks of -11° Celsius and > months of winter we had 31° more yesterday, including sunshine, > and i went for cycling. Then someone reported a brain-damage of > mine in software i maintain, and i had to make a release, and then > it was about 3 o'clock in the morning. > > --steffen > |Der Kragenbaer,The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-M2bf743adc6f944f181ccc6e4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] go1.13.1 build fails
Thank you David for the binaries. On Mon, Oct 7, 2019 at 1:38 AM Lucio De Re wrote: > In fact, I'd forgotten I'd had an exchange with a Go developer (I wish > I could remember who) precisely over that "bootstrap" issue. Go1.4.3 > needs a small enhancement, I forget from which target onwards because > of some executable binary improvement even for Linux. But the > bootstrap version is the recommended one, recently, as I mentioned. > > Here is Brad's message: > > --- cut --- > You'll want to use the release-branch.go1.4 branch, not Go 1.4.3. > > See https://golang.org/doc/install/source#go14 which says: > > > To build a bootstrap toolchain from source, use either the git branch > release-branch.go1.4 or go1.4-bootstrap-20171003.tar.gz, which contains the > Go 1.4 source code plus accumulated fixes to keep the tools running on > newer operating systems. (Go 1.4 was the last distribution in which the > toolchain was written in C.) After unpacking the Go 1.4 source, cd to the > src subdirectory, set CGO_ENABLED=0 in the environment, and run make.bash > (or, on Windows, make.bat). > > --- cut --- > > On 10/7/19, David du Colombier <0in...@gmail.com> wrote: > > I'd recommend bootstrapping Go with one of > > the recent binary package available on: > > > > http://9legacy.org/download.html > > > > There might be issues when bootstrapping from Go 1.4. > > Also, plan9/arm support started with Go 1.7. > > > > -- > > David du Colombier > > > > > > > -- > Lucio De Re > 2 Piet Retief St > Kestell (Eastern Free State) > 9860 South Africa > > Ph.: +27 71 471 3694 > Cell: +27 83 251 5824 > >
Re: [9fans] What are you using Plan 9 for?
I've been using it with Klong ( http://t3x.org/klong/index.html ) lately which supports plan9 natively. On Sat, Jun 16, 2018 at 6:39 AM, Ole-Hjalmar Kristensen wrote: > I cannot really say I am using Plan9 for anything serious, although I have > both Plan9 and 9Front running on a couple of old laptops. I keep them around > mainly to see if I can grok the ideas and maybe steal some of them :-) > > But I run the Plan9port tools on both Linux and Solaris, and occasionally > Inferno on Windows, when I want a sane environment there. Acme is my main > editor these days. The 'everything is text' approach works very well when > developing on multiple paltforms (Solaris, Linux, BSD, Windows). In Acme, > the left button combined with the plumber is really usefull when jumping > from a debug printout in the log to the source code. I run Vac/Venti on > Linux as my backup system both at home and at work. > > If I ever get some spare time, I intend to set up a cron job to replicate > the contents between the two Venti servers. > > > > On Thu, Jun 14, 2018 at 5:53 AM, 刘宇宝 wrote: >> >> Compared to "not for you", "don't care", "intend to not be successful", I >> like more the topic of cat-v irc channel on freenode set by aiju: "fun >> fact: you can use multiple operating systems at the same time". >> >> Certainly Plan 9 can't replace Linux/macOS/BSD/Windows, I'm still curious >> its upper bound for a sensible daily usage, and the best practice from you >> happy experienced Plan 9 users. >> >> I checked mail headers in this mailing list, seems all use Apple Mail, >> iPhone Mail, WebMail with AJAX, Gmail(a lot), ProtonMail, these emails went >> through Postfix and Exim servers, probably on Linux. >> >> In great harmony, we use kinds of operating system and kinds of software >> on them. >> >> Regards, >> Yubao Liu >> >> > On Jun 14, 2018, at 10:53 AM, N. S. Montanaro wrote: >> > >> > I think a lot of people discover Plan 9 and want it to be something it >> > isn’t, rather than stumble upon it out of necessity. As the FQA says, “Plan >> > 9 is not for you." >> >
Re: [9fans] Uriel
This comes as a shock to me. Uriel was a great guy; we worked together on a few things, his deep understanding of very complex mechanisms always amazed me. J.
Re: [9fans] known working wifi cards
I use a Vonets USB WiFi Bridge vap11g I found on ebay for less than $10, I wrote a little driver to have it set its channel and ssid. I didn't have any documentation, so I snooped the usb traffic bridged to a windows instance running in virtualbox. Jerome On Wed, Mar 21, 2012 at 9:10 AM, Stanley Lieber stanley.lie...@gmail.com wrote: On Wed, Mar 21, 2012 at 11:02 AM, Richard Miller 9f...@hamnavoe.com wrote: aka Lucent Orinoco Silver aka IBM High Rate Wireless LAN etc. Firsthand experience only ? Perhaps it's a faulty assumption that all PC24E-H-FC cards are created equal. I've seen them branded many different ways. -sl
[9fans] VESA issue on VIA EPIA SN18000G
9fans, I'm using a VIA SN18000G booting off a fileserver, everything seems to be working relatively well, however it seems that the video card is not recognized. My 'pci -bv' and 'vga -lvp' are as follows: cpu% pci -bv 0.0.5: --- 08.00.20 1106/5364 0 VIA Technology 0.15.0: disk 01.01.8f 1106/5287 5 0:cc01 16 1:c881 16 2:c801 16 3:c481 16 4:c401 16 5:fcfffc00 1024 VIA Technology 0.15.1: disk 01.01.8a 1106/0571 255 4:fc01 16 VIA Technology VT82C686B/VT823x/A/C Bus Master IDE Controller 0.18.0: net 02.00.00 1106/3065 11 0:c001 256 1:fcfff800 256 VIA Technology VT6103 Rhine II PCI Fast Ethernet Controller 1.0.0: vid 03.00.00 1106/3371 11 0:dc08 67108864 1:fd00 16777216 VIA Technology P4M900 VIA Chrome9 HC IGP 128.1.0:aud 04.03.00 1106/3288 5 0:fe3fc000 16384 VIA Technology 040300 VIA VT8251/8237A High Definition Audio Controller - HDA Codec Realtek ALC660 3.0.0: net 02.00.00 1106/3119 10 0:d801 256 1:fe2ffc04 256 2: 16 VIA Technology VT6120/VT6121/VT6122 'Velocity' Gigabit Ethernet Controllers cpu% aux/vga -lvp dbvesa: VBE error 0x4f00 aux/vga: controller not in /lib/vgadb, not vesa 0xC 55 AA 6F E9 98 00 F2 6E 64 DD A6 03 00 00 00 00 U.ond... 0xC0010 00 00 00 00 00 00 00 00 44 00 BA FB 45 00 49 42 D...E.IB 0xC0020 4D 20 43 4F 4D 50 41 54 49 42 4C 45 42 43 50 4F M COMPATIBLEBCPO 0xC0030 53 54 00 00 18 00 30 35 2F 31 30 2F 30 37 00 09 ST05/10/07.. 0xC0040 00 C0 C6 05 50 43 49 52 06 11 71 33 00 00 18 00 PCIR..q3 0xC0050 00 00 00 03 40 00 51 01 00 80 00 00 00 01 20 20 @.q... 0xC0060 20 56 49 41 20 30 30 50 44 4C 34 36 45 00 00 20 VIA 00PDL46E.. 0xC0070 56 54 33 33 36 34 20 20 20 45 6D 62 65 64 20 20 VT3364 Embed 0xC0080 20 20 4E 6F 54 56 20 95 00 00 05 56 65 72 30 35NoTV Ver05 0xC0090 20 20 20 20 20 20 20 20 20 20 20 20 00 00 56 BE ..V. 0xC00A0 06 00 2E 8B 5C 04 2E 8C 4F 02 2E 8C 4F 12 2E 8B \...O...O... 0xC00B0 5F 10 2E 8C 4F 04 5E E8 0B B7 9C FA 1E 55 2E 8E _...O.^..U.. 0xC00C0 1E A1 71 B8 D5 6E 2E F6 06 42 00 01 74 03 B8 D2 ..q..n...B..t... 0xC00D0 6E A3 40 00 8C 0E 42 00 E8 3E 6F C7 06 B4 01 D5 n...@...b..o. 0xC00E0 6E 8C 0E B6 01 C7 06 08 01 65 F0 C7 06 0A 01 00 ne.. 0xC00F0 F0 C7 06 0C 01 00 04 8C 0E 0E 01 C7 06 7C 00 00 .|.. main-snarf vga-snarf vga-dump vga misc 67 vga feature 00 vga sequencer03 00 03 00 02 vga crt 5F 4F 50 82 55 81 BF 1F - 00 4F 0D 0E 00 00 07 8A 9C EE 8F 28 1F 96 B9 A3 - FF vga graphics 00 00 00 00 00 10 0E 00 - FF vga attribute00 01 02 03 04 05 14 07 - 38 39 3A 3B 3C 3D 3E 3F 0C 00 0F 08 00 vga virtual 0 0 vga panning off vga apz 0 vga linear 0 vmf 25175000 vmdf 0 vf1 0 vbw 0 vga-init dbdumpmode type=vga, size=640x480x1 frequency=25175000 x=640 (0x280), y=480 (0x1E0), z=1 (0x1) ht=800 (0x320), shb=664 (0x298), ehb=760 (0x2F8) shs=664 (0x298), ehs=760 (0x2F8) vt=525 (0x20D), vrs=491 (0x1EB), vre=493 (0x1ED) hsync=0, vsync=0, interlace=0 vga-dump vga flag Fdump|Finit|Fsnarf vga misc E3 vga feature 00 vga sequencer03 01 0F 00 06 vga crt 5F 4F 52 9F 53 1F20B 3E - 00 40 00 00 00 00 00 00 1EB 2D1DF 28 001EB1EC C3 -7FF vga graphics 00 00 00 00 00 00 05 0F - FF vga attribute00 01 02 03 04 05 06 07 - 08 09 0A 0B 0C 0D 0E 0F 01 FF 0F 00 00 vga virtual 640 480 vga panning off vga apz 0 vga linear 0 main-load +vgactlw type vga sequencer-enter on sequencer-leave on vgactlw: type vga: bad VGA control message type vga aux/vga: vgactlw: type vga: bad VGA control message type vga Is there any way to force this card to use the VESA driver? Please note that I'm booting using *norealmode= in my plan9.ini. Sincerely, Jerome
[9fans] VESA issue on VIA EPIA SN18000G
9fans, VESA requires realmode. Thank you Erik, it was an oversight from my part. I was able to start rio in 1024x768x8 and 1280x1024x8 using the VESA driver, however, the keyboard was not working, and the pointer had no cursor. Please note, that, while the pointer had no cursor, the mouse was working fine, and I was able to open windows, although I couldn't type anything in them. This is what I bind (cpurc) before starting rio: for (i in m i S t U P) bind -a '#'^$i /dev /dev/null [2=1] Please note that I'm using a PS/2 mouse and keyboard, and I am not starting the usb daemon. Finally, the keyboard works fine at the Plan9 boot prompt. Should this matter, aux/vga doesn't use the '-c' option. Any thoughts? Jerome
Re: [9fans] Netbooting from Qemu
As it appears, the (net)boot configuration, meaning the 'plan9.ini' located in /cfg/pxe/, where '' is the netbooted host ethernet address, was missing nvram parameters, preventing the cpu kernel (9pccpu) to proceed with the boot sequence. If this parameter (nvram or nvr) is present, but incorrectly set, the netbooted host will prompt for the machine's hostowner's key. If this parameter is missing, the boot sequence halts. Therefore I would like to ask the 9fans community what are the best practices to host the nvram key in a diskless environment, in either a qemu virtualized machine or physical hardware. I am aware of serial Eeproms connecting to parallel ports to store the nvram data ( http://rs-rlab.narod.ru/9nvram.html ), I find it a good solution, but unfortunately, most modern hardware doesn't necessarly include a parallel port anymore, or even a floppy disk. I assume (perhaps incorrectly) that the netbooted host can not use a nvram store located on kfs. Please share with the list if you are aware, or use a different method to store your nvram data, either in virtualized machines or physical hardware. Preferably without the use of disk/floppy storage. Sincerely, Jerome
[9fans] Netbooting from Qemu
Hi, I am (net)booting a Qemu instance from a Plan 9 fileserver named colossus(192.168.1.40) running cwfs, an authserver, named cerberus(192.168.1.50) is also present in the same domain. The client is named cpu-003(192.168.1.33), it retrieves, via dhcp its plan9.ini, which is as such: bootfile=ether0!/386/9pccpu.gz bootargs=tcp!192.168.1.40!564 -D fs=192.168.1.40 auth=192.168.1.50 sysname=cpu-003 *nomp=1 *debugload=1 *nodumpstack=1 The dhcpd configuration uses /lib/ndb/local to properly serve dhcp queries, relevants bits as follow: ipnet=drawterm.com ip=192.168.1.0 ipmask=255.255.255.0 dnsdomain=drawterm.com authdom=drawterm.com ipgw=192.168.1.1 dns=192.168.1.1 ntp=192.168.1.1 auth=cerberus fs=colossus cpu=cpu-001 smtp=192.168.1.1 ip=192.168.1.33 sys=cpu-003 ether=525400123456 dom=drawterm.com bootf=/386/9pxeload proto=tcp When booting a 9pc kernel (which means that bootfile=ether0!/386/9pc.gz) the system boots, then prompt for a user login, secstore password and behaves as a terminal, as one can expect. When booting a 9pccpu kernel (with the configuration above, and not another change from the 9pc kernel) the system hangs as such (please notice that I have ipconfig debug mode turned on in the bootargs): [...] ipconfig: parsebootp: new packet ipconfig: parseoptions: type(53) len 1, bytes left 71 ipconfig: parseoptions: lease(51) len 4, bytes left 68 ipconfig: parseoptions: serverid(54) len 4, bytes left 62 ipconfig: parseoptions: ipmask(1) len 4, bytes left 56 ipconfig: parseoptions: ipgw(3) len 4, bytes left 50 ipconfig: parseoptions: sys(12) len 12, bytes left 44 ipconfig: parseoptions: dns(6) len 4, bytes left 30 ipconfig: parseoptions: dom(15) len 3, bytes left 24 ipconfig: parseoptions: ntp(42) len 4, bytes left 19 ipconfig: parseoptions: nil(43) len 12, bytes left 13 ipconfig: got ack from 192.168.1.40 ipconfig: lease=1800 ipconfig: ipaddr=192.168.1.33 ipmask=255.255.255.0 ipconfig: ipgw=192.168.1.1 ipconfig: dns=192.168.1.1 ipconfig: ntp=192.168.1.1 ipconfig: parseoptions: nil(128) len 4, bytes left 10 ipconfig: parseoptions: nil(129) len 4, bytes left 4 ipconfig: fs=192.168.1.40 ipconfig: auth=192.168.1.50 ipconfig: new ipaddr=192.168.1.33 new ipmask=255.255.255.0 new ipgw=192.168.1.1 ipconfig: server=192.168.1.40 sname=colossus Then the system hangs, the cwfs console reports that no connection was established from cpu-003(192.168.1.33), while, when booting a 9pc kernel, the connection is established and the boot sequence follows. Finally, replacing 'tcp!192.168.1.40!564' by 'tcp' or 'tcp!colossus!564' leads to the same results, I do not believe it to be a misconfiguration however as 9pc is booting properly. Despite that 9pccpu is hanging, I am able to ping this host cpu-003(192.168.1.33) therefore the network card has been found and initialized properly. A 'snoopy' reports that after the last dhcp queries, no packets are ever sent from cpu-003(192.168.1.33). What would cause this configuration to boot using a stock 9pc kernel but not a 9pccpu one? I've even increased the memory allocation of the Qemu instance as I would expect a 9pccpu kernel to be slightly bigger than a 9pc one. Any suggestion? Jerome
Re: [9fans] Building new kernel.
9, mk: no recipe to make 'pptpd.8' in directory /sys/src/cmd/ip does /sys/src/cmd/ip/pptpd.c exist? if not, there must be an error in the pull database on sources. you can copy it by hand with 9fs sources cp -x /n/sources/plan9/sys/src/cmd/ip/pptpd.c /sys/src/cmd/ip/ Erik, it already exists and has the same MD5 checksum than the one in sources. Jerome
Re: [9fans] Building new kernel.
9, mk: no recipe to make 'pptpd.8' in directory /sys/src/cmd/ip does /sys/src/cmd/ip/pptpd.c exist? if not, there must be an error in the pull database on sources. you can copy it by hand with 9fs sources cp -x /n/sources/plan9/sys/src/cmd/ip/pptpd.c /sys/src/cmd/ip/ Erik, it already exists and has the same MD5 checksum than the one in sources. Using July 19th's iso and today's (Tue Jul 22 13:51:21 PDT 2008) pull: http://www.eskimo.com/~jibanes/pull.png Hope this helps, Jerome
Re: [9fans] Building new kernel.
what i know is a) it build just fine on my system, but i don't use pull. b) if for some xyzw mk requires xyzw.8 and there's no xyzw.$x so that there's a mk rule like so %.8: %.$x, i get the following error message ; mk xyzw.8 mk: no recipe to make 'xyzw.8' in directory /sys/src/9/pc since i know there's a rule %.8: %.c, there must be some reason that mk thinks that pptp.c doesn't exist. i have no idea what that would be. mode bits? pptpd.c is dated Dec 31, 1969, mk doesn't like this. So I touch'd it, and then it compiled just fine. Jerome
Re: [9fans] Building new kernel.
Bob, mk: don't know how to make '/386/bin/fossil/fossil' in directory /sys/src/9/pc touch /386/bin/fossil/fossil then you can mk 'CONF=pcf' if you want. Hope this helps, Jerome Ibanes
[9fans] Plan 9 on a SunPCI card.
I would like to install Plan 9 on a SunPCI IIIpro card (1), currently
located in a old Sun Blade 150 (2). This card has an Athlon XP 2200
(1600Mhz) and currently has 768MB of memory; it works in (almost) any pci
sparc v9 system running Solaris/OpenSolaris.
Interestingly enough, this card can either use a harddrive image to boot
(which is more or less a raw drive image located on the Solaris partition
with a somewhat specific 1024 bytes header, which happens to be rather
easy to forge) or a physical harddrive attached to its internal IDE
connector (which is 44 pins, laptop sized).
I haven't found a way to boot this card from a cdrom using the plan9
cdrom (3), even when such cdrom is directly attached to this card (please
note that Debian boots fine from there, when a plan9 cdrom is inserted I
get the famous Operating System not found, although I haven't spent a
lot of time investigating this issue the fact that Debian boots seems not
to indicate a hardware issue). It seems that the internal floppy slot is
not working (by design) and this card can not network (pxe) boot (although
it has a network port) directly (it can network boot thru grub when grub
is compiled with --enable-diskless and support for the right network
chipset, and finally placed on a diskimage, more on this later).
I was able, however to generate a diskimage from a plan 9 raw disk
image (4), 9load starts normally, but can not find an attached
harddrive (it however displays booting options to be fd0 and ether0):
pcirouting: South bridge 1106, 3177 not found
might be the issue. By looking at /sys/src/9/pc/pci.c it *seems* that
making a disk image with:
{ 0x1106, 0x3177, viaget, viaset }, /* Viatech VT8235 */
would tremendously help. Do you think the lack of a recognized South
bridge would prevent 9load to find an attached harddrive, or would 9load
use INT13 to do so?
I have also tried to boot this card from network by using grub to do so,
therefore I have generated a disk image with support for the Via Rhine II
chipset (as present on the SunPCI IIIpro) built in into grub but
unfortunately, after fetching 9load via tftp the card cycles almost
immediately. Has anyone been able, or is currently using grub to boot
9load, if so, would any extra parameters be required?
Finally, assuming building 9load with support for the South bridge doesn't
help, could anyone think about any other way to run plan 9 on the SunPCI?
Sincerely,
Jerome Ibanes
References:
(1) SunPCI card: http://www.sun.com/desktop/products/sunpcipro/
(2) Sun Blade: http://www.sun.com/desktop/workstation/sunblade150/
(3) http://plan9.bell-labs.com/plan9/download/plan9.iso.bz2
(4) using this: http://www.oszoo.org/wiki/index.php/Plan9_070107.zip
[9fans] Plan 9 on a SunPCI card.
[...]
pcirouting: South bridge 1106, 3177 not found
{ 0x1106, 0x3177, viaget, viaset }, /* Viatech VT8235 */
[...]
could you send the output of linux lspci -vvn?
The output of linux's lspci -vvn is attached to this message, thank you
for looking into this.
Sincerely,
Jerome Ibanes00:00.0 0600: 1106:3156
Subsystem: 1106:3156
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort+ SERR- PERR-
Latency: 8
Region 0: Memory at e800 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans-
64bit- FW+ AGP3- Rate=x1,x2,x4
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW-
Rate=none
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.0 0604: 1106:b091 (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort+ SERR- PERR+
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: ec00-ec0f
Prefetchable memory behind bridge: e000-e7ff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0b.0 0680: 8086:b555 (rev 03)
Subsystem: 108e:676a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 32 (8000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 12
Region 0: Memory at ec1c (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at d000 [size=256]
Region 2: Memory at 000d (low-1M, non-prefetchable) [size=64K]
Region 3: Memory at ec10 (32-bit, non-prefetchable) [size=512K]
Region 4: Memory at ec18 (32-bit, prefetchable) [size=256K]
Capabilities: [dc] Power Management version 0
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [e4] Vital Product Data
Capabilities: [ec] #06 [0080]
00:10.0 0c03: 1106:3038 (rev 80) (prog-if 00 [UHCI])
Subsystem: 1106:3038
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 32, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 4: I/O ports at d400 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:10.3 0c03: 1106:3104 (rev 82) (prog-if 20 [EHCI])
Subsystem: 1106:3104
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin D routed to IRQ 5
Region 0: Memory at ec1c1000 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:11.0 0601: 1106:3177
Subsystem: 1106:3177
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping+ SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 0
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:11.1 0101: 1106:0571 (rev 06) (prog-if 8a [Master SecP PriP])
Subsystem: 1106:0571
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency:
[9fans] Plan 9 on a SunPCI card.
I haven't found a way to boot this card from a cdrom using the plan9
cdrom (3), even when such cdrom is directly attached to this card (please
note that Debian boots fine from there, when a plan9 cdrom is inserted I
get the famous Operating System not found, although I haven't spent a
lot of time investigating this issue the fact that Debian boots seems not
to indicate a hardware issue).
This was an oversight from my part, I am now able to boot a plan 9 (or any
other) bootable cdrom.
I was able, however to generate a diskimage from a plan 9 raw disk
image (4), 9load starts normally, but can not find an attached
harddrive (it however displays booting options to be fd0 and ether0):
pcirouting: South bridge 1106, 3177 not found
might be the issue. By looking at /sys/src/9/pc/pci.c it *seems* that
making a disk image with:
{ 0x1106, 0x3177, viaget, viaset }, /* Viatech VT8235 */
would tremendously help. Do you think the lack of a recognized South
bridge would prevent 9load to find an attached harddrive, or would 9load
use INT13 to do so?
As I understand it, the fact that the South Bridge wasn't recognized
shouldn't prevent 9load for finding more boot devices, especially the
cdrom one. Recognizing the South Bridge shouldn't be a showstopper,
assuming the bios implementation is good, which is a fair assumption here.
Disabling DMA didn't help; but what appears to be confusing is that
/sys/src/boot/pc/sdata.c shows support for the 1106:0571 (please refer to
my previous post which includes the lspci output):
/sys/src/boot/pc/sdata.c:
case (0x057116)|0x1106: /* VIA 82C686 */
lspci output:
00:11.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.1 0101: 1106:0571 (rev 06) (prog-if 8a [Master SecP PriP])
Sincerely,
Jerome Ibanes
