Fwd: Re: zlib-1.1.4 out - security fix
Bill Maltby LFS Related
lfsbill at wlmlx1.wlmcs.com
Wed Mar 13 05:47:47 PST 2002
I'm starting to feel guilt, so after this, I'm taking my part of this
thread to the Local beer hall.
On Wed, 13 Mar 2002, Ian Molton wrote:
> the CPU mode bits get put on the address bus too, giving a 64 bit address
> range, which, with the standard MEMC controller is split up so you have
> 32MB virtual addrerss space in user mode, 16MB physical address space on
> top of that, some IO above that, and then writing to the space above that
> programs the MMU mappings, and reading from it reads from up to 12MB of ROM
> address space.
> Its an interesting arch, as the memory controller has no connections to the
> data bus - its programmed entirely by dummy writes to the ROM space.
> likewise, the video chip from the system has no address bus connections, as
> the video dma and address selection is driven by the memory controller.
> all this was done to reduce the pin count on the packaging, to lower cost
> of the chipset.
> the whole thing is completely asynchronous too - the CPU can run at a
> different speed from MEMC and the video controller.
> Its cool ;-)
> I just love the way the engineers have crammed what they can into every
> available bit, not like todays bloatware.
Yes. That was akin to "craftsmanship" and "elegance". You don't see much
of either anymore. Too bad. :-(
> A few months. I've been hitting heisenbugs.
Well, not unusual. Half the time I know where I'm at but not which way I'm
headed. The rest of the time, that's inverted. And when I try figure out
both at once, I seem to get Alzheimer's.
> Its very lonely. as far as I know I am the ONLY person attempting to run
> linux on this machine.
Well, _you_ better not get Alzheimer's! ;-)
> It /used/ to have a working port, around 2.0.xx but Im working on 2.4 and a
> LOT of the code has 'rotted'.
Speaking of which, how's the hardware holding up. Anything besides the IDE
drives occasionally need repair? What do you do then?
> function tests (tests stack).
> > > It will start, init a framebuffer, and even load and run simple
> > > programs. however a call to fork() will kill things in short order -
> > > the child runs, but the parent does not ;-)
Same in real life - parents get worn down, children just keep running us
> > What's the prognosis, Doc? Think you'll find the cure eventaully?
> As long as the poor machine doesnt die before I do. I have to power cycle
> it to get the netcard to reset, and the harddisc isnt loving that. (its IDE
> though, so at least thats not a porblem).
billm at wlmcs.com
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-security' in the subject header of the message
More information about the lfs-security