Hi, I've just uploaded the latest batch of binary packages for 1.6.2. The total number is now 2,164 packages. Included are manually built pine, pico, and imap, since there was a security problem with pine 4.58. Please let me know if you have any problems with these. Otherwise, enjoy! John Klos -- -- Panem et circences.
I wanted to do some system-independent testing and I didn't want to do it on a production machine, so I started on my VAX (a VAXstation 3100 m38 with serial console). It had a beta of 1.6 on it and could not quickly find corresponding source, so I put 1.6.2 on it. I encountered several programs. With the install.ram kernel, and also once with GENERIC, console output stopped after the kernal messages. At the point where one would expect that it would switch to "the wrong" console. Either it just hangs, or the output is lost. Strangely enough this does not happen with a self-compiled kernel, either of 1.6.2 or older, nor with previous GENERIC and install kernels I had used. When I re-test this, GENERIC does not exhibit this problem anymore. With a self-compiled kernel (or GENERIC), console output is ok, but various programs dump core during multiuser startup, and it becomes impossible to login since sshd and login are two of them. Fortunately I can still run with the 1.6_BETA2 kernel and 1.6.2 userland. Any ideas? I thought it might be some COMPAT option but I turned them all on but it didn't help. After that, retrying GENERIC also failed in the same way, so it doesn't seem to be a kernel building problem. Output from self-compiled kernel: >>> b p(Continue reading)
Fortunately, these problems are fixed in -current. I cross-built yesterday's -current and installed it. Works so far. -Olaf. -- -- ___ Olaf 'Rhialto' Seibert \X/ rhialto/at/xs4all.nl -- Cetero censeo "authored" delendum esse.
While building a custom kernel for the VAX, I came across undefined
references to memcpy and memset, from bf_skey.o and sha2.o.
Looking through definitions for memcpy I found various things that might
be relevant. Apparently none of these kick in.
lib/libkern/bcopy.c:66
/*
* Copy a block of memory, handling overlap.
* This is the routine that actually implements
* (the portable versions of) bcopy, memcpy, and memmove.
*/
#ifdef MEMCOPY
void *
memcpy(dst0, src0, length)
#else
#ifdef MEMMOVE
void *
memmove(dst0, src0, length)
#else
void
bcopy(src0, dst0, length)
#endif
#endif
void *dst0;
const void *src0;
size_t length;
{
(Continue reading)
Hello, I've picked up my work with LCG HW acceleration where i left it few months ago; i can now inject command packets into FIFO (at least small number of them, i haven't tried to fill the FIFO entirely yet to see whether it wraps around correctly) and i have two basic functions working - one is block copy (memcpy(), except that it can handle visual blocks of framebuffer memory, such as rectangles on the screen, not just linear memory like memcpy() does) and the other one is bitwise rasterops function (it can perform any of the 16 basic operations on a rectangle with stencil, like copy, clear, set, AND, OR, XOR, etc.). Block copy function is good enough for console scrolling use (since our rectangle always starts at the start of each line) but i have yet to figure out how to copy blocks around the screen (like moving windows under GUI). Bitwise ops seem work perfectly though, i just set address of top left pixel of rectangle, its dimensions, stencil to be used and operation to be performed and it just works, which means blanking (or setting, etc. depending on the operation to be executed) a rectangle in the middle of the screen is just as easy as blanking entire screen. In plain english: this means VS 4000 VLC and model 60 will have HW acceleration support added to console code which should (hopefully) speed up scrolling, blanking, etc., the most commonly used operations on large amounts of data that were now performed by the CPU. I have absolutely no experience with X servers so i cannot integrate any of that stuff into one (or write one from scratch). If anybody happens to have 4000 VLC/M60 and is willing to do X server work i can send him the relevant information. I suppose console driver will have to provide access to FIFO to external applications (like it does now for(Continue reading)
Hello, How does one allocate a block of memory of given size, say 64 KB, like malloc(), except that i want this block to be (A) aligned to 64 KB boundary in memory space, (B) be a contiguous block of physical memory and (C) i need to know its physical address rather than virtual address. There are some other *alloc() functions i noticed but no docs describing them so i was wondering if anybody knows how to get that block allocated as described above - please let me know ASAP, i'm stuck with my LCG FIFO code (i overflow FIFO in short-circuit mode so i need to operate with real FIFO and this requires said block of memory). Blaz Antonic -- -- Hi! I'm a signature virus! Copy me into your signature to help me spread!
At 05:54 PM 6/8/2004, Blaz Antonic wrote: >Hello, > >How does one allocate a block of memory of given size, say 64 KB, like >malloc(), except that i want this block to be (A) aligned to 64 KB >boundary in memory space, (B) be a contiguous block of physical memory >and (C) i need to know its physical address rather than virtual address. > >There are some other *alloc() functions i noticed but no docs describing >them so i was wondering if anybody knows how to get that block allocated >as described above - please let me know ASAP, i'm stuck with my LCG FIFO >code (i overflow FIFO in short-circuit mode so i need to operate with >real FIFO and this requires said block of memory). Since this is for a device, you should be using bus_dmamem_alloc and related functions. You need to use a segment count of 1 to force a large contiguous block. -- -- Matt Thomas email: matt <at> 3am-software.com 3am Software Foundry www: http://3am-software.com/bio/matt/ Cupertino, CA disclaimer: I avow all knowledge of this message.
On Tue, 08 Jun 2004 17:54:14 -0700 Blaz Antonic <blaz.antonic <at> siol.net> wrote: > How does one allocate a block of memory of given size, say 64 KB, like > malloc(), except that i want this block to be (A) aligned to 64 KB > boundary in memory space, (B) be a contiguous block of physical memory > and (C) i need to know its physical address rather than virtual > address. A sequence of bus_dmamem_alloc() bus_dmamem_map() bus_dmamap_create() bus_dmamap_load() should do what you want. See sys/dev/sbus/isp_sbus.c:isp_sbus_mbxdma() or sys/arch/hp700/gsc/if_iee_gsc.c:iee_gsc_attach() for an example. -- -- tschüß, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
Hello, After Jochen helped me out with the bus_dma[mem,map]* functions i apparently managed to break something on my own - now only bitmap rendering works, i have yet to figure out how i managed to break rasterops. Anyway, i wandered a bit off-topic: sys/arch/vax/if/if_le/vsbus.c is missing bus_dmammem_unmap() calls in its attach function. I mentioned the probelm with sys/arch/vax/incluyde/lcgreg.h the other day but here it goes again, just in case: offsets for RESIDUE_LW0 and LW1 are wrong; LW2 is correct. Offsets for LW0 and LW1 should be 1 longword higher up so all three residual LWs form contiguous block of 12 bytes. Blaz Antonic -- -- Hi! I'm a signature virus! Copy me into your signature to help me spread!
> Hello, > > After Jochen helped me out with the bus_dma[mem,map]* functions i > apparently managed to break something on my own - now only bitmap > rendering works, i have yet to figure out how i managed to break > rasterops. > > Anyway, i wandered a bit off-topic: sys/arch/vax/if/if_le/vsbus.c is > missing bus_dmammem_unmap() calls in its attach function. > Yes, Jochen sent me a mail yesterday about this. This bug is mostly cosmetic; if the kernel fails to attach the on-board lance chip then there are bigger problems than just a few lost pages of memory-- Ragge BTW thanks for your great work on the LCG stuff! It's really cool to (at last!) get the graphics working.
RSS Feed2 | |
|---|---|
58 | |
98 | |
37 | |
263 | |
27 | |
2 | |
5 | |
4 | |
5 | |
31 | |
86 | |
46 | |
24 | |
32 | |
31 | |
1 | |
4 | |
5 | |
3 | |
6 | |
7 | |
5 | |
26 | |
14 | |
1 | |
5 | |
5 | |
13 | |
12 | |
68 | |
15 | |
9 | |
28 | |
28 | |
11 | |
81 | |
6 | |
3 | |
1 | |
5 | |
2 | |
4 | |
9 | |
11 | |
21 | |
20 | |
35 | |
109 | |
194 | |
39 | |
23 | |
3 | |
7 | |
4 | |
32 | |
4 | |
7 | |
48 | |
77 | |
32 | |
2 | |
9 | |
33 | |
12 | |
27 | |
59 | |
7 | |
25 | |
100 | |
41 | |
24 | |
12 | |
20 | |
8 | |
21 | |
31 | |
3 | |
12 | |
19 | |
7 | |
19 | |
88 | |
57 | |
11 | |
68 | |
52 | |
17 | |
3 | |
18 | |
2 | |
27 | |
32 | |
73 | |
46 | |
20 | |
46 | |
55 | |
18 | |
51 | |
17 | |
53 | |
103 | |
33 | |
26 | |
62 | |
72 | |
70 | |
126 | |
126 | |
98 | |
72 | |
50 | |
34 | |
119 | |
58 | |
119 | |
83 | |
190 | |
132 | |
167 | |
188 | |
182 | |
356 | |
66 | |
33 | |
159 | |
279 | |
315 | |
227 | |
63 | |
1 | |
1 |
