#59: Support for SMSC FDC37M60X Super I/O
--+-
Reporter: uwe | Owner: uwe
Type: enhancement | Status: new
Priority: major | Milestone:
#60: Change 'ram' to 'RAM' in user-visible output
--+-
Reporter: uwe | Owner: uwe
Type: enhancement | Status: new
Priority: minor |
Also when it comes to enabling the IDE controller in compatibilty mode
(reg 0x42) the non working versions reports it contains 0xc9, the
working version reports the same register as 0.
You need to set the prog-if field in the PCI config space
for the controller to 0x8a, not 0x8f, before doing
On 12/11/06, Adam Talbot [EMAIL PROTECTED] wrote:
Like always I am looking for a faster boot time. So an idea came to
me. My current speed system loads Linuxbios. Then the 2.6.18 kernel,
until it reaches the suspend2 code (www.suspend2.net). At that point it
resumes from the suspend file,
Sure, but I guess an ICE/ICD (In-Circuit-Emulator/Debugger) for a
modern CPU will cost a couple of hundred thousand dollars.
For a modern processor, ICE means something different than what you
are thinking of. NO one debugs with a true ICE any more,
Not no one -- but for the purposes we're
Acked-by is just a comment saying who approved this going into the
SVN
tree, it is completely separate; it should probably be called
Approved-by or something like that. I don't really see it having any
real purpose, but maybe that's just me :-)
In firmware development the risk of
* The notification emails sent by Trac to the mailing list don't
contain the patches.
http://trac.edgewall.org/ticket/2259
Until this is fixed, it is nice to send the patches you put
in Trac to the ML separately, for discussion. Please note
the ticket number too then :-)
Segher
--
* Segher Boessenkool [EMAIL PROTECTED] [061211 17:13]:
Oh, I fully understand why patches should be reviewed by
other people, and why someone senior should approve
patches before they are committed to the SVN tree.
I'm just challenging the usefulness of the Acked-by tag
in the commit
I'm just challenging the usefulness of the Acked-by tag
in the commit message.
Oh this is simple: The commit message is used as the interface to
the subversion server. There is no other way of easily handling a
successful review on basis of commit hooks.
Ah okay, got it.
As soon as abuild
My 2.6.18 kernel comes off the disk, so filo. Currently the 2.6.18
kernel need to load, just a little, to set up memory and disk in order
to access the disk and the suspend file. Also, you must use the same
kernel rev. But I am thinking much lower. This perhaps would be best
as a patch to
* Segher Boessenkool [EMAIL PROTECTED] [061211 18:07]:
abuild runs great. I have not seen any bug reports in a whole
while.
It won't do crossbuilds still no?
It did from the very first day. You need an appropriate cross compiler
installed and in your path though.
S.
--
coresystems GmbH •
That is on ATI chipset.
I am working on one AM2+MCP55 based MB and then someone could use that
for PVR or DTC.
For laptop support, I need to double check the code about mem support. I
only verify the code for AM2 and socket F for Rev F CPU.
YH
--
linuxbios mailing list
I am having a great deal of difficulty figuring out how to enable the
cache on my board. Using memtest86 it is quite obvious that the cache
is not running at its correct speed.
Is this something I enable in the chipset code or the mainboard code?
I tried grepping through the source and I
On Monday 11 December 2006 18:57, Adam Talbot wrote:
Forget the nice way
that suspens2 works, by only pulling the used RAM to the suspend image;
I always hated the silly way windows works on hibernation - at least you can
use a list of used pages and just write them out to speed it up,
Is the suspend be the job of OS instead of firmware?
I wonder if kexec or kdump could load another kernel to dump previous
kernel to disk partition or file.
Also wonder if you have one kernel to use kexec reload one dumped image?
YH
--
linuxbios mailing list
linuxbios@linuxbios.org
On Mon, Dec 11, 2006 at 10:59:26AM -0800, Lu, Yinghai wrote:
Is the suspend be the job of OS instead of firmware?
That's an interesting question. Proprietary BIOSes used to do suspend to disk
- I had a laptop 7 years ago that did it (HP Omnibook XE2). Every laptop I've
owned since then does not
abuild runs great. I have not seen any bug reports in a whole
while.
It won't do crossbuilds still no?
It did from the very first day.
Heh, not for me ;-)
You need an appropriate cross compiler
installed and in your path though.
I'll try it out again, I have *many* (100 or so)
Ward Vandewege [EMAIL PROTECTED] writes:
On Mon, Dec 11, 2006 at 10:59:26AM -0800, Lu, Yinghai wrote:
Is the suspend be the job of OS instead of firmware?
That's an interesting question. Proprietary BIOSes used to do suspend to disk
- I had a laptop 7 years ago that did it (HP Omnibook XE2).
* Lu, Yinghai [EMAIL PROTECTED] [061211 19:59]:
Is the suspend be the job of OS instead of firmware?
LinuxBIOS' effort has indeed been the other way around: Move everything
into the OS that is not necessarily a task of the firmware.
Since we have this no-callback paradigm in the LLFW we should
* Eric W. Biederman [EMAIL PROTECTED] [061211 20:48]:
Beyond that I think you are likely to get a lot more users and a lot
more debugging and testing if you put the work in the OS.
One drawback with Linux suspend is both suspend and recover speed. Or
the lack thereof. I have not seen a laptop
Stefan Reinauer [EMAIL PROTECTED] writes:
* Lu, Yinghai [EMAIL PROTECTED] [061211 19:59]:
Is the suspend be the job of OS instead of firmware?
LinuxBIOS' effort has indeed been the other way around: Move everything
into the OS that is not necessarily a task of the firmware.
Since we have
On 12/11/06, Eric W. Biederman [EMAIL PROTECTED] wrote:
Suspend to RAM currently appears to be something that the OS cannot do alone.
At
least because cpu wakeup has to go through the BIOS.
Beyond that I think you are likely to get a lot more users and a lot more
debugging
and testing
Well, I am very glad to see all the input on this idea. Lets see if I
can add some info and sort what we have.
Current speeds.
My current system takes about 3 seconds for Linuxbios, then 2 more for
kernel, to the suspend2 code, then 7~12sec depending on how much
compression I am using on the
Is this motherboard supported by Linux BIOS?
lspci -v output
:00:00.0 Host bridge: Silicon Integrated Systems [SiS] 645xx (rev 71)
Subsystem: Silicon Integrated Systems [SiS] 645xx
Flags: bus master, medium devsel, latency 32
Memory at e000 (32-bit,
YH How about remove the soft_reset_x in cache_as_ram_auto.c?
That indeed got it to boot, but the HTX card doesn't show up in
lspci in Linux, so it's still not coming up quite right. Any more
ideas to try? I'm thankful for your help and happy to keep banging
on it as long as you are. :)
-mcq
Bootlog?
YH
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Bootlog?
Attached at 8. Lemme know if you want the full spew.
-mcq
--
[EMAIL PROTECTED]
--
http://www.fastmail.fm - Faster than the air-speed velocity of an
unladen european swallow
minicom.cap.gz
Description: GNU Zip compressed data
--
linuxbios mailing
My bad.
The southbridge is an NVIDIA CK804. Unfortunately there's a few km between
my PC and Internet access right now, so I'll have to get back to you about
lspci.
Does the CK804 come in many flavours?
--
linuxbios mailing list
linuxbios@linuxbios.org
28 matches
Mail list logo
