It is really
root=LABEL=root
The syntax looks funny but it worked for me.
regards,
einar
Constantine 'Gus' Fantanas wrote:
> einar_linux wrote:
>> ...
>> Grub then looks:
>> kernel /boot/vmlinuz root=LABEL=root bla bla bla
>>
> Are you sure it is not
> kernel /boot/vmlinuz root=LABEL/root... (instead of
> root=LABEL=root... --two equal signs around 'LABEL')?
>
> Thanks for the very informative posting!
>
> cf
>
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-amd64+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-amd64+help(a)opensuse.org
I have an MSI K8D-Master-F motherboard with two Opteron 244's.
It recently got retasked as a desktop machine due to another
system's failure...I thought the little ATI Rage built into
the motherboard would make more than a sufficient 2d desktop
type framebuffer, and as far as other stuff inside this box...
this should be a pretty kick ass, high performance workstation.
But I can literally watch the screen redraw if I switch virtual
desktops. Painfully slow. Thinking this was just some
crippled built-in video bug, I threw in an old nVidia card
we had lying around in one of the regular PCI slots. Slightly
slower, if you can believe it.
I think this:
mtrr: type mismatch for e5000000,1000000 old: uncachable new: write-combining
And of course this:
$ cat /proc/mtrr
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
Has something to do with it (and may also explain why I'm getting
less than stellar performance out of other PCI devices, such as
the RAID array that has a 128MB memory region the driver directly
reads and writes on). The above is with the nVidia PCI card
inserted, the built-in ATI card would also emit a similar mtrr
rejection message, just the address is different, and the system
would only list 512MB uncachable without the nVidia.
Also notice that there's 4GB installed in this machine, in 2 2GB
DIMMs installed in one bank together. And yet the BIOS map:
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000bfff0000 (usable)
BIOS-e820: 00000000bfff0000 - 00000000bffff000 (ACPI data)
BIOS-e820: 00000000bffff000 - 00000000c0000000 (ACPI NVS)
BIOS-e820: 00000000ff7c0000 - 0000000100000000 (reserved)
Lists nothing beyond the 4GB mark where that memory might
reasonably have been moved to. Assuming this is just a
neglectful BIOS, I tried setting 'mem=4G' and 'memmap=1G@4G'
kernel options, to define the 1GB 'hole' I presume is being
placed here, and which got me this added line to dmesg:
user: 0000000100000000 - 0000000140000000 (usable)
But still only 3GB available.
To add even more insult to rising injury, I noticed while
looking through dmesg that the IOMMU is being disabled. It
appears the value being advertised by the CPU's:
CPU 0: aperture @ 1b80000000 size 128 MB
Is being rejected because it lies (WELL) above the 4GB mark.
I've been going through archives and I'm not finding anything
that looks like actionable advice.
The latest BIOS MSI's webpage lists for this motherboard is 1.1:
already installed. It has no option for 'pci hole: software'.
The only options I'm finding are memory bank interleaving (which
I tried disabling), and 'Disabled/Best-Fit/Absolute' settings
for the IOMMU, as well as its aperture size (128M, which I
might increase if it would be used rather than ignored...).
One post in the archive that matched on motherboard make and
model looks confused to me, because he refers to his BIOS as
AWARD 2.0, but the only BIOS MSI puts out for this board is
AMI (versioned 1.1).
In summary what I'd like to know is:
1) Where is the 'go fast' button? re: pci video that's slower than
even isa video should be (and presumably similar performance
problems on other PCI devices).
2) How do I get the last 25% of my memory back?
3) How do I get the system to put the IOMMU somewhere in the range
it stole under 4G (so Linux can use it)? Can Linux move this on
its own accord?
Thanks in advance for any and all help.
--
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
Hello,
I've had a problem that drove me nuts for a couple of
weeks. The microphone works fine but recording sound
had an issue.
The problem I faced was that when I recorded (using
KRecord) the sound will be too low and far and
unclear.
For a couple of weeks, I could not get my hand on the
"move" that would fix it. However, every now and then
I got it working. But when I reboot, or start a new
session it goes back to old unclear and low sound.
What drove me nuts was the fact that every time I get
it working, it's after a different series of steps
than the last time I did it. So for a while I was just
in trial and error period.
Last week I finally figured out the specific "move"
or "step", which fixes the problem. What I needed to
do, is open Kmix, and go to the "Switches" tab and
then just shuffle the the three "Input Source" fields
that I have. After I shuffle them, I bring them back
to the same setup of "Mic", "Front Mic", "Line". Then
it works. Note that before I did the shuffling, the
three fields were in that same exact order!
That's as far as I got trying to debug this issue.
Has anybody faced this? I would like to know, if
anybody has had this, before I dig deeper into the
problem to find out what actually changes when I start
a new session (and what happens when I do this
shuffling).
My sound card is: Audio device: Intel Corporation
82801H (ICH8 Family) HD Audio Controller (rev 02)
I'm using alsa driver: Advanced Linux Sound
Architecture Driver Version 1.0.12rc1.
OS: openSUSE 10.2.
CPU: Intel core 2 duo. 64-bit.
Regards,
Majdi Jaqaman
____________________________________________________________________________________
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-amd64+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-amd64+help(a)opensuse.org
Hello list,
I find a strange problem now.
The system is openSuSE 10.2 x86-64 (2.6.18.8-0.1-default).
When I was used gdb, this was generated. the following are the procedures.
[foo] > ps
PID TTY TIME CMD
29508 pts/5 00:00:00 bash
29545 pts/5 00:00:00 ps
And switches to another terminal "bar" here.
[bar] > gdb -q -p 29508
Attaching to process 29508
[...]
0x00002b9129d41200 in __read_nocancel () from /lib64/libc.so.6
(gdb) p write(1, "Hallo, SuSE\n", 12)
$1 = 12
Then check the "foo" terminal.
[foo] > Hallo, SuSE
Ok, let's advance processing on the "bar" terminal.
(gdb) c
Continuing.
Program exited normally.
(gdb)
Suddenly, the bash as "foo" exited here. I was expecting to stop at the
"Continuing.". but I don't know what the cause.
Does anyone know this cause?
Thanks,
eshsf
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-amd64+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-amd64+help(a)opensuse.org