Re: [9fans] fun with replica and pull
I experienced the same when pulling system files after some time of not upgrading. Also, I am pretty sure that I have not modified those files listed as modified locally. I tried pull -s *, but it did not work at all. Thanks, Peter.
Re: [9fans] fun with replica and pull
> pull -s * This will not work. You need to pull each file that is marked as modified, prefixed by the -s option to take the server (the labs) version or -c to keep the version you have locally (and silence the error). It is the work of moments to load the debug printed by pull -v into favorite plan9 editor, and modify it into a command line to fetch the modified files. -Steve
Re: [9fans] fun with replica and pull
yes, I expected that. thanks! Peter On Tue, Dec 20, 2011 at 10:17 AM, Steve Simon wrote: ...
Re: [9fans] fun with replica and pull
On Tue Dec 20 01:03:05 EST 2011, j...@jfloren.net wrote: > I'd like to install Erik's nupas, but according to contrib/install, a > bunch of files have been modified locally, so it doesn't install them. > Then, if I try to do a contrib/pull, it believes the package is up to > date. Ok, great, so I do "replica/pull -v /dist/replica/nupas", which > still complains that a ton of files are locally modified. As far as I > can tell, you must specify each individual file in a -s switch to > replica before it'll actually do the right thing--yuck. Is there any > way for me to just install the thing and damn the consequences? I've > looked at the list of files it's afraid to overwrite, they're not > anything I made modifications to (or at least, no important > modifications). if you're feeling like a really big hammer, why not run pull once, run through sed/awk/whatever to generate a complete list of -s'es and run pull again? disgusting, no? - erik
Re: [9fans] Intel X4500 Integrated Graphics support
On Tue Dec 20 02:41:29 EST 2011, aku...@mail.nanosouffle.net wrote: > My Thinkpad X200s has an Intel X4500 card, > but vga(3) defaults to using vesa. Has anyone > added any support for this card lately? Or is > there any other vga `type' that can be set in > /dev/vgactl, which would offer better > performance than vesa, for this card? i think most people are using vesa. unfortunately that limits one to 4:3 graphics modes. which kernel are you using? if you get write-combining going through pat or mtrr, and use double buffering, things should be pretty good on most hardware. (true of the kernels you could download today.) - erik
Re: [9fans] Intel X4500 Integrated Graphics support
On Tue, Dec 20, 2011 at 7:52 AM, erik quanstrom wrote:
> i think most people are using vesa. unfortunately
> that limits one to 4:3 graphics modes.
Some card/monitor combinations seem to support other aspect ratios
that are technically outside of the VESA spec. For example, my NVidia
GeForce 8400GS coupled with an NEC AccuSync AS221WM 22" via DVI-D[1]
happily runs[2] at the monitor's native resolution of 1680x1050 with
VESA, which is 16:10. I was also able to achieve 1680x1050 on the
AS221WM with an Intel GMA 3000 via VGA. The deciding factor seems to
be whatever modes are contained in the specific VESA BIOS that is in
your specific video card.
Note: depending upon the monitor, and depending upon how the card is
connected to the monitor, the VESA BIOS may present the user with
different available modes. Typically, aux/vga -p will produce
different output when the same hardware is connected via VGA, DVI-D,
HDMI, etc.
-sl
[1]
term% @{rfork n; aux/realemu; aux/vga -p}
fd 00FD00384C1F5311000A202020202020
vesa flagUlinear|Hlinear|Fsnarf
vesa sigVESA 3.0
vesa oemNVIDIA 96.134
vesa vendor NVIDIA Corporation
vesa productG86 Board - p413h05
vesa revChip Rev
vesa cap 8-bit-dac
vesa mem14680064
vesa mode 0x100 640x400x8 m8 packed
vesa mode 0x101 640x480x8 m8 packed
vesa mode 0x103 800x600x8 m8 packed
vesa mode 0x105 1024x768x8 m8 packed
vesa mode 0x107 1280x1024x8 m8 packed
vesa mode 0x10e 320x200x16 r5g6b5 direct
vesa mode 0x10f 320x200x32 x8r8g8b8 direct
vesa mode 0x111 640x480x16 r5g6b5 direct
vesa mode 0x112 640x480x32 x8r8g8b8 direct
vesa mode 0x114 800x600x16 r5g6b5 direct
vesa mode 0x115 800x600x32 x8r8g8b8 direct
vesa mode 0x117 1024x768x16 r5g6b5 direct
vesa mode 0x118 1024x768x32 x8r8g8b8 direct
vesa mode 0x11a 1280x1024x16 r5g6b5 direct
vesa mode 0x11b 1280x1024x32 x8r8g8b8 direct
vesa mode 0x130 320x200x8 m8 packed
vesa mode 0x131 320x400x8 m8 packed
vesa mode 0x132 320x400x16 r5g6b5 direct
vesa mode 0x133 320x400x32 x8r8g8b8 direct
vesa mode 0x134 320x240x8 m8 packed
vesa mode 0x135 320x240x16 r5g6b5 direct
vesa mode 0x136 320x240x32 x8r8g8b8 direct
vesa mode 0x13d 640x400x16 r5g6b5 direct
vesa mode 0x13e 640x400x32 x8r8g8b8 direct
vesa mode 0x160 1280x800x8 m8 packed
vesa mode 0x161 1280x800x32 x8r8g8b8 direct
vesa mode 0x162 768x480x8 m8 packed
vesa mode 0x168 1680x1050x8 m8 packed
vesa mode 0x169 1680x1050x32 x8r8g8b8 direct
edid mfrNEC
edid serialstr 03105090TA
edid name AS221WM
edid product26562
edid serial 0
edid version1.3
edid mfrdate2010.10
edid size (cm) 47x30
edid gamma 2.20
edid vert (Hz) 56-76
edid horz (Hz) 31000-83000
edid pclkmax17000
edid flags digital standby suspend activeoff
edid 640x480@60Hz
clock=25.175
shb=648 ehb=792 ht=800
vrs=490 vre=492 vt=525
hsync=- vsync=-
edid 640x480@73Hz
clock=31.5
shb=648 ehb=824 ht=832
vrs=489 vre=492 vt=520
hsync=- vsync=-
edid 640x480@75Hz
clock=31.5
shb=640 ehb=840 ht=840
vrs=481 vre=484 vt=500
hsync=- vsync=-
edid 800x600@56Hz
clock=36
shb=800 ehb=1024 ht=1024
vrs=601 vre=603 vt=625
hsync=+ vsync=+
edid 800x600@60Hz
clock=40
shb=800 ehb=1056 ht=1056
vrs=601 vre=605 vt=628
hsync=+ vsync=+
edid 800x600@72Hz
clock=50
shb=800 ehb=1040 ht=1040
vrs=637 vre=643 vt=666
hsync=+ vsync=+
edid 800x600@75Hz
clock=49.5
shb=800 ehb=1056 ht=1056
vrs=601 vre=604 vt=625
hsync=+ vsync=+
edid 1024x768@60Hz
clock=65
shb=1024 ehb=1344 ht=1344
vrs=771 vre=777 vt=806
hsync=- vsync=-
edid 1024x768@70Hz
clock=75
shb=1024 ehb=1328 ht=1328
vrs=771 vre=777 vt=806
hsync=- vsync=-
edid 1024x768@75Hz
clock=78.75
shb=1024 ehb=1312 ht=1312
vrs=769 vre=772 vt=800
hsync=+ vsync=+
edid 1280x1024@75Hz
clock=135
shb=1280 ehb=1688 ht=1688
vrs=1025 vre=1028 vt=1066
hsync=+ vsync=+
edid 1680x1050@60Hz
clock=146.25
shb=1784 ehb=1960 ht=2240
vrs=1053 vre=1059 vt=1089
Re: [9fans] Intel X4500 Integrated Graphics support
> Some card/monitor combinations seem to support other aspect ratios > that are technically outside of the VESA spec. For example, my NVidia > GeForce 8400GS coupled with an NEC AccuSync AS221WM 22" via DVI-D[1] > happily runs[2] at the monitor's native resolution of 1680x1050 with > VESA, which is 16:10. I was also able to achieve 1680x1050 on the > AS221WM with an Intel GMA 3000 via VGA. The deciding factor seems to > be whatever modes are contained in the specific VESA BIOS that is in > your specific video card. i never considered the advertized modes might depend on the monitor connected. have you observed this? also, the old code set paddr to the start of the bar, your code sets it to whatever the vbe mode returned. have you observed this, too? - erik
Re: [9fans] Intel X4500 Integrated Graphics support
On Tue, Dec 20, 2011 at 9:03 AM, erik quanstrom wrote: > > i never considered the advertized modes might depend on > the monitor connected. have you observed this? Yes. I have a few combinations of VGA-VGA, DVI-DVI, VGA-DVI, DVI-HDMI, etc., cables, and, using the same card and monitor, I get different output from aux/vga -p depending upon the combination. I've observed this with other cards and monitors as well. It seems like the card firmware does some kind of autodetection to figure out which modes it wants to present. > also, the old code set paddr to the start of the bar, your code > sets it to whatever the vbe mode returned. have you observed > this, too? Attempting 1680x1050x32 was hanging my machine[1]. Cinap identified the problem and provided the fix. I can't speak much on the code as I don't really understand the mechanism. -sl [1] http://www.flickr.com/photos/stanleylieber/6403274727/in/set-72157627976638191/
Re: [9fans] fun with replica and pull
Replica(8) is bad at overlaying several sources... Perhaps contrib(1) should hide this somehow.
Re: [9fans] fun with replica and pull
On Tue, Dec 20, 2011 at 5:23 AM, erik quanstrom wrote: > if you're feeling like a really big hammer, why not run pull > once, run through sed/awk/whatever to generate a complete > list of -s'es and run pull again? > > disgusting, no? it reminds me of why we went with hg on the NIX tree. ron
Re: [9fans] fun with replica and pull
On Dec 20, 2011, at 12:57 PM, ron minnich wrote: > > it reminds me of why we went with hg on the NIX tree. > because at the time you did it things like bitbucket and the hg port came to exist? so what one should do, use replica to sync with sources and move the all the contribs to bitbucket google code?
Re: [9fans] fun with replica and pull
2011-12-20 17:09, Federico Benavento skrev: On Dec 20, 2011, at 12:57 PM, ron minnich wrote: it reminds me of why we went with hg on the NIX tree. because at the time you did it things like bitbucket and the hg port came to exist? so what one should do, use replica to sync with sources and move the all the contribs to bitbucket google code? That sounds like a pretty good idea :) I played with a similar idea with the http://code.google.com/p/ports2plan9/ I am however still a beginner (I hope to improve my Plan9 skills and learn as I go along with various (increasingly advanced) porting efforts without actually having an "agenda" or aim as such), but if people want to upload their contribs to that repository they are free to do so. By the way - is someone working on an update of the Python2 port? and what about the hg-git plugin? Just wondering if I should start playing with those or leave that to someone else.
[9fans] ssh-agent
I ported Russ's ssh agent to plan9 for use with the native, and linuxemu openssh implementations. The program is a protocol converter parsing requests from openssh and extracting the keys from factotum as requited. Code in /n/sources/contrib/steve/ssh-agent.tgz -Steve
[9fans] aux/cpuid
i added a bit of goo to decode the processor features and extended features, dupo; aux/cpuid -ief Intel(R) Xeon(R) CPU X5650 @ 2.67GHz dx nox gb rdtscp amd64 cx lahf64 dx fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pbe cx sse3 pclmulqdq dtes64 mon dscpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse41 sse42 popcnt aes (contrib quanstro/cpuid). one surprise came out of this, for some reason x2apic does not appear to be supported on most newish intel processors. - erik
Re: [9fans] fun with replica and pull
On Mon, Dec 19, 2011 at 10:00 PM, John Floren wrote: > I'd like to install Erik's nupas, but according to contrib/install, a > bunch of files have been modified locally, so it doesn't install them. > Then, if I try to do a contrib/pull, it believes the package is up to > date. Ok, great, so I do "replica/pull -v /dist/replica/nupas", which > still complains that a ton of files are locally modified. As far as I > can tell, you must specify each individual file in a -s switch to > replica before it'll actually do the right thing--yuck. Is there any > way for me to just install the thing and damn the consequences? I've > looked at the list of files it's afraid to overwrite, they're not > anything I made modifications to (or at least, no important > modifications). > > > John I ended up writing "decontrib", which will download all the files from a contrib package into a local directory and make a tarball for you. Then you can do whatever you like. Thus: % decontrib quanstro nupas [lots of output removed] % ls | grep nupas nupas nupas.tgz % lc nupas 386 README acmemailrc sys % It's in /n/sources/contrib/john/decontrib
[9fans] /dev/etherfile
/sys/src/cmd/usb/ether/ether.c says * BUG: This should use /dev/etherfile to * use the kernel ether device code. Which sounds promising, but I can't seem to find any references to etherfile anywhere else. Does it exist? tristan -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] Intel X4500 Integrated Graphics support
I have tried 1280x800x32 on the laptop and 1280x1024x16 and 1280x1024x32 on a monitor connected to the laptop via VGA. In all cases, the result is a very, very incredibly slow and choppy rio. I'm using the stock Plan 9 kernel (with a patch for IL (*shakes fist at the 'Labs*)). ak On Tue, Dec 20, 2011 at 5:52 AM, erik quanstrom wrote: > i think most people are using vesa. unfortunately > that limits one to 4:3 graphics modes. > > which kernel are you using? if you get write-combining > going through pat or mtrr, and use double buffering, > things should be pretty good on most hardware. > (true of the kernels you could download today.) > > - erik >
Re: [9fans] Intel X4500 Integrated Graphics support
On Tue Dec 20 23:57:09 EST 2011, aku...@mail.nanosouffle.net wrote: > I have tried 1280x800x32 on the laptop and > 1280x1024x16 and 1280x1024x32 on a monitor > connected to the laptop via VGA. In all cases, > the result is a very, very incredibly slow and > choppy rio. > > I'm using the stock Plan 9 kernel (with a patch > for IL (*shakes fist at the 'Labs*)). there could be many things wrong. if you're having a mtrr issue, then 9atom should fix it, since i gave mtrrs a pass since they are depricated and require hooks into the clock interrupt. but i'm wondering if rio is the only thing that's choppy on your system. why don't you send pci output? it's too bad you don't have the 9atom mods to /dev/irqalloc that would let us know if you have a ringing irq. - erik
