> the *mp=400 line should be on the top right before *mp0= ... sorry
> about that. (9boot quirk :-))
Works on my T61.
-sl
the *mp=400 line should be on the top right before *mp0= ... sorry
about that. (9boot quirk :-))
--
cinap
excellent, thanks.
- boot linux, save dmesg.
- boot 9front with *dumpmp= option, then save /dev/kmesg output.
--
cinap
> i merged the info into the mp table from that T61, but
> i got the dmesg from the a random google search so it
> might be wrong. someone provide me with a linux dmesg
> of that machine?
I should be getting my T61 tonite so I can provide the output
for you in case nobody responds before then.
-
wrote a awk script that generate iointr mp table
entries from linux dmesg output.
i merged the info into the mp table from that T61,
but i got the dmesg from the a random google search
so it might be wrong. someone provide me with a linux
dmesg of that machine?
anyway, theres the mptable override
no. the i/o apics are programmed like before as specified in the iointr
entry from the mp table. i have no way differentiating if this is a
real isa bus or some compatibilty hack or just plain wrong mp table.
i looked in openbsd code and just figured they allow sharing edge
interrupts so i just re
> as i said before, this mp table of this machine identity maps
> all irq's to isa interrupts wich are edge triggered. mpintrenablex()
> code refused to share edge triggered interrupts causing half the usb
> controllers not receiving ther irq's in mp mode.
that's probablly just wrong. have you tr
should add irq type and interrupt counts to a arch file like
erik did in 9atom. but for now, some awk did the trick.
theres the mp table from sl's t61. (sorry for the raw nature of
this dump)
processor: 00 00 14 03 FB 06 00 00 FF FB EB BF 00 00 00 00 00 00 00 00
processor: 00 01 14 01 FB 06 00 0
On Tue May 15 10:14:38 EDT 2012, burton.samog...@markit.com wrote:
>
> > seems pretty clear that your mp table is junk. too bad.
>
> Ironic given I bought an Intel MB to keep from having problems like this.
intel generally doesn't provide complete mp tables.
- erik
> seems pretty clear that your mp table is junk. too bad.
Ironic given I bought an Intel MB to keep from having problems like this.
--
Burton Samograd
This e-mail, including accompanying communications and attachments, is strictly
confidential and only for the intended recipient. Any retentio
> Eric, I noticed you have a blade server which I would guess means
> they work with plan9. I was looking at them yesterday; are there
> particular models that work well/at all?
the hs23 does work with the intel 82599 or myricom 10gbe mezzanine
cards. no emulex support at this time.
i have had
On Tue May 15 08:20:29 EDT 2012, burton.samog...@gmail.com wrote:
> On Tue, May 15, 2012 at 3:31 AM, erik quanstrom wrote:
> > i'd be interested in if a 9atom kernel works on this machine.
> > (hget http://ftp.quanstro.net/other/9pccd.gz) unfortunately, i don't
> > think i can easily boot to a cw
In any case my T61 should be showing up today or tomorrow so I'll
have dedicated computer for my plan9 experiments. Hopefully that
will work better as it was recommended by some others on the list.
Eric, I noticed you have a blade server which I would guess means
they work with plan9. I was look
On Tue, May 15, 2012 at 3:31 AM, erik quanstrom wrote:
> i'd be interested in if a 9atom kernel works on this machine.
> (hget http://ftp.quanstro.net/other/9pccd.gz) unfortunately, i don't
> think i can easily boot to a cwfs root file system.
I trued the 9atom kernel and I got similar messages
> I tried removing *nomp and adding *msi and got similar errors,
> but with ioapicenable and mpreenable. The disks got recognized
> a lot faster this time, which was better, but my keyboard didn't work :-/
> I can't really capture the full output as a lot of it scrolls off the screen
> but I can
> Here's some relevant output of linux dmesg regarding MP on my machine:
[...]
> [0.00] Using ACPI (MADT) for SMP configuration information
i think this is the salient bit. linux is not using the mp tables. it's using
acpi.
- erik
> > > On the Thinkpad T61, the hard drive is sometimes not detected on the
> > > first attempt. After thirty seconds or so it usually succeeds and
> > > boots as normal.
> >
> > have you done any debugging of this? that sounds like a condition i haven't
> > observed.
>
> On my Thinkcentre M55 the
On Mon May 14 22:57:54 EDT 2012, s...@9front.org wrote:
> > > Can you try getting rid of *nomp=1 and setting *msi=1
> > >
> >
> > I tried removing *nomp and adding *msi and got similar errors,
> > but with ioapicenable and mpreenable. The disks got recognized
> > a lot faster this time, which was
> > Can you try getting rid of *nomp=1 and setting *msi=1
> >
>
> I tried removing *nomp and adding *msi and got similar errors,
> but with ioapicenable and mpreenable. The disks got recognized
> a lot faster this time, which was better, but my keyboard didn't work :-/
> I can't really capture the
> > On the Thinkpad T61, the hard drive is sometimes not detected on the
> > first attempt. After thirty seconds or so it usually succeeds and
> > boots as normal.
>
> have you done any debugging of this? that sounds like a condition i haven't
> observed.
On my Thinkcentre M55 there is actually a
On Mon, May 14, 2012 at 8:36 PM, Burton Samograd
wrote:
>>> So no MP for this machine for now.
Here's some relevant output of linux dmesg regarding MP on my machine:
[0.00] found SMP MP-table at [880fe200] fe200
[0.00] initial memory mapped : 0 - 2000
[0.00] B
On Mon, May 14, 2012 at 8:05 PM, wrote:
>> It was an MP problem. I had commented out *nomp=1 in my plan9.ini
>> and after I tried to boot again and saw a number of errors with
>> mpintreenable and intreenable I put it back in and it booted correctly.
>> So no MP for this machine for now.
>
> Can
> Can you try getting rid of *nomp=1 and setting *msi=1
>
> On the Thinkpad T61, the hard drive is sometimes not detected on the
> first attempt. After thirty seconds or so it usually succeeds and
> boots as normal.
have you done any debugging of this? that sounds like a condition i haven't
obse
> maybe the bios leaves the sata drives in some unusable
> state (only) when booting from harddrive?
i don't see how. controller reset should comreset the drives.
it's almost got to be an interrupt issue.
- erik
> It was an MP problem. I had commented out *nomp=1 in my plan9.ini
> and after I tried to boot again and saw a number of errors with
> mpintreenable and intreenable I put it back in and it booted correctly.
> So no MP for this machine for now.
Can you try getting rid of *nomp=1 and setting *msi=
> so looks like jammed interrupt problem?
It was an MP problem. I had commented out *nomp=1 in my plan9.ini
and after I tried to boot again and saw a number of errors with
mpintreenable and intreenable I put it back in and it booted correctly.
So no MP for this machine for now.
Of course I screw
if hes using 9front, then eriks ahci driver should support
puis. there also should have been different diagnostic prints
when it failed to spinup looking at ahciidentify().
so looks like jammed interrupt problem? is the cdrom also sata
or is it ide?
what puzzles me is that you said it booted fine
On Sun, 13 May 2012 18:22:02 -0600
Burton Samograd wrote:
> > 9bootfat does its search by walking all partition table
> > entries (primary and secondary) on the bootdrive that
> > are marked as "active".
>
> Reading the grub docs, it sounds like an active partition is marked
> bootable and only
> 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port
> SATA AHCI Controller (rev 02)
> 03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6101/6102
> single-port PATA133 interface (rev b1)
i assume that you're attached to 00:1f:2, the sata controller due to the
Attached is the output of lspci. I'll see if I can get it to fully
boot to get the output of the other command.
--
Burton
On Sun, May 13, 2012 at 8:56 PM, erik quanstrom wrote:
> On Sun May 13 21:20:40 EDT 2012, burton.samog...@gmail.com wrote:
>> Toggling the bootable flag on the plan9 partiti
On Sun May 13 21:20:40 EDT 2012, burton.samog...@gmail.com wrote:
> Toggling the bootable flag on the plan9 partition did allow it to start
> booting.
> It then looked to be iterating over the drives, where on my harddisks I got:
>
> sdE0
> bad disk
> bad disk
> bad disk
> bad disk
> bad disk
i
Toggling the bootable flag on the plan9 partition did allow it to start booting.
It then looked to be iterating over the drives, where on my harddisks I got:
sdE0
bad disk
bad disk
bad disk
bad disk
bad disk
sdE5
bad disk
bad disk
bad disk
bad disk
bad disk
This happened for both of my SATA har
> 9bootfat does its search by walking all partition table
> entries (primary and secondary) on the bootdrive that
> are marked as "active".
Reading the grub docs, it sounds like an active partition is marked
bootable and only one partition can be marked that way. Currently my
linux partition is m
the pbs managed to load 9bootfat but 9bootfat wasnt able
to find the fat partition it came from.
we pass 32bit lba's to the bios read sector routines,
so theres nothing inside 9boot itself that would prevent
this from working i think.
9bootfat does its search by walking all partition table
entrie
Hello
I just installed 9front onto the second partition of my main SSD drive
and when I boot
using grub with 'chainloader +1' I get a PBS check which looks to pass
and then the
message 'no fat'. I am thinking that my installation might be out of
sector range on the
drive; I installed on the secon
35 matches
Mail list logo
