I've read through the MMU code more than
a few times and never noticed this. Who
reads past tmpunmap anyways? ;)
Anthony
diff -c /sys/src/9/pc/mmu.c /tmp/mmu.c
/sys/src/9/pc/mmu.c:934,940 - /tmp/mmu.c:934,940
void*
kaddr(ulong pa)
{
- if(pa > (ulong)-KZERO)
+ if(pa >= (ulong)
John Floren writes:
> After the initial install, did you reboot pretty soon? Venti wants to spend
> some time writing an initial image after the first boot, it seems, and if
> you interrupt that you're in trouble
Whenever possible, I use fshalt when shutting down. (The only excepting
being lock
On Fri Mar 18 06:32:08 EDT 2011, al...@pbrane.org wrote:
> I've read through the MMU code more than
> a few times and never noticed this. Who
> reads past tmpunmap anyways? ;)
>
> Anthony
>
> diff -c /sys/src/9/pc/mmu.c /tmp/mmu.c
> /sys/src/9/pc/mmu.c:934,940 - /tmp/mmu.c:934,940
> void*
>
erik quanstrom writes:
>> it's a bad day and you're going to need to think about a new hard
>> drive or motherboard.
>
> there's an easy way to test this. since you can boot
> from the live cd, just reboot into the live cd and
I booted the install CD, turned on DMA, dd'd the disk to /dev/null.
Did you zero the plan 9 partition first? I recall having a problem like this
when installing over an existing plan 9 installation, all i had to do was
zero that partition and everything worked fine after that.
I have seen similar symptoms. In the end, I narrowed my problems down
to a very particular combination of hard drive and laptop.
The installation would complete fine, but I would get i/o errors
running plan9 from the (pata) hard disk. I tried with and without dma
and rwm. "dd" read and write test
On Fri, Mar 18, 2011 at 9:12 AM, Jacob Todd wrote:
> Did you zero the plan 9 partition first? I recall having a problem like this
> when installing over an existing plan 9 installation, all i had to do was
> zero that partition and everything worked fine after that.
Yes, be sure to try this. A c
try a write test. also, you may want to check out how venti/fossil
have repartitioned their play areas. i believe i've seen them mess
up the size calculations.
- erik
theres a first attempt of a parallel dial implementation that doesnt
need shared memory to coordinate the the spawning:
/n/sources/contrib/cinap_lenrek/dial.c
it will run at maximum Maxconcurr connects in parallel at a time
until there are no more addresses to connect to left, a connection
is est
On Fri Mar 18 19:23:13 EDT 2011, cinap_len...@gmx.de wrote:
> theres a first attempt of a parallel dial implementation that doesnt
> need shared memory to coordinate the the spawning:
>
> /n/sources/contrib/cinap_lenrek/dial.c
>
> it will run at maximum Maxconcurr connects in parallel at a time
>
Another thought - did you let the installer automatically parttition your disk
or did you do it manually - if you overlap partitions or extend one of the
partitions off the end of the disk you can get similar nasty results.
just a random guess.
-Steve
I don't know guys, these sure look like disk errors to me ...
ron
On Fri Mar 18 20:03:00 EDT 2011, rminn...@gmail.com wrote:
> I don't know guys, these sure look like disk errors to me ...
no need to guess, fill the partitions with 0s with dd. if that
works, then we know it's a bug in venti.
- erik
On Fri Mar 18 21:08:09 EDT 2011, quans...@quanstro.net wrote:
> On Fri Mar 18 20:03:00 EDT 2011, rminn...@gmail.com wrote:
> > I don't know guys, these sure look like disk errors to me ...
>
> no need to guess, fill the partitions with 0s with dd. if that
> works, then we know it's a bug in venti
r...@hemiola.co.uk writes:
> I have seen similar symptoms. In the end, I narrowed my problems down
> to a very particular combination of hard drive and laptop.
Interesting. The system that's misbehaving is a laptop, as well. Its
specs:
IBM ThinkPad T23
ATA ST94813A, 78140160 * 512 byte sector
> erik quanstrom writes:
>
> > try a write test. also, you may want to check out how venti/fossil
> > have repartitioned their play areas. i believe i've seen them mess
> > up the size calculations.
>
> I wiped the entire Plan 9 partition with "dd if=/dev/zero of=/dev/sda3",
> which completed
check the output of cat /dev/sdC0/ctl for lba48always.
i have it enabled on my t23 because i got i/o erros (on a particular
block number that i forgot... it was reproducable) if its off.
thats what i have in my termrc:
echo dma on >/dev/sdC0/ctl
echo lba48always on >/dev/sdC0/ctl
the machine r
On Fri Mar 18 22:48:04 EDT 2011, cinap_len...@gmx.de wrote:
> check the output of cat /dev/sdC0/ctl for lba48always.
>
> i have it enabled on my t23 because i got i/o erros (on a particular
> block number that i forgot... it was reproducable) if its off.
i don't really think this is the problem
On Fri, Mar 18, 2011 at 7:53 PM, erik quanstrom wrote:
> i don't really think this is the problem, since a dd on the whole
> disk worked.
If you have a bad bit of memory it can result in exactly these sorts
of problems. Seen on a T23 I used to have, esp. when it decided to get
too warm. There ar
makes sense... this was a long time ago... :)
--
cinap
--- Begin Message ---
On Fri Mar 18 22:48:04 EDT 2011, cinap_len...@gmx.de wrote:
> check the output of cat /dev/sdC0/ctl for lba48always.
>
> i have it enabled on my t23 because i got i/o erros (on a particular
> block number that i forgot.
lie! T23 never fails! ;-)
--
cinap
--- Begin Message ---
On Fri, Mar 18, 2011 at 7:53 PM, erik quanstrom wrote:
> i don't really think this is the problem, since a dd on the whole
> disk worked.
If you have a bad bit of memory it can result in exactly these sorts
of problems. Seen on a T23 I us
21 matches
Mail list logo
