Martin Hamilton wrote:
> FWIW, I didn't have any luck with the 2.4.3 swsusp-v8pre3 patch - my
> C1VE suspended to disk, but on re-reading the memory image from swap
> space the machine reset and we were back to the LILO prompt & fsck.
I can confirm Martin's experience, I got the same results.
A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
(cc'd to the acpi list, where people have also been talking about
this recently...)
Ookhoi writes:
| I tried swsusp on my vaio (also a c1ve :-) and it didn't work because it
| (said it) couldn't stop [kre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
"Grover, Andrew" writes:
| I don't think I understand that first sentence. (Let me respond anyways ;-)
Doh! Sorry, what I meant was that (if I'm understanding this right!)
the AML interpreter being embedd
> > > I was wondering whether the swsusp work might form a useful basis
> > > for the eventual ACPI implementation of the to-disk hibernation
> > > stuff:
> >
> > I (and others) have looked at it. It's a pretty cool patch, but it
> > really isn't the right way to do things.
>
> swsusp is most de
> > I was wondering whether the swsusp work might form a useful basis for
> > the eventual ACPI implementation of the to-disk hibernation stuff:
>
> I (and others) have looked at it. It's a pretty cool patch, but it really
> isn't the right way to do things.
swsusp is most definitely the right
> From: Martin Hamilton [mailto:[EMAIL PROTECTED]]
> | ACPI is meant to abstract the OS from all the "magic
> numbers". It's very
> | possible to do things in a platform-specific way, but if
> you want to handle
> | all platforms, you'd end up with something ACPI-like.
>
> This isn't me talking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
"Grover, Andrew" writes:
| (BTW, read the ACPI 2.0 spec - it's a lot better)
I'm getting there... perhaps tomorrow :-))
| ACPI is meant to abstract the OS from all the "magic numbers". It's very
| possib
> From: Martin Hamilton [mailto:[EMAIL PROTECTED]]
> Pardon me for butting in, but perhaps this is relevant...
>
> I've seen the odd program which manipulates the ACPI tables/registers
> directly rather than through an ASL compiler then an AML interpreter.
> These appear to use the "magic numbers
> > | that is intentional - first things first.
>
> Probably that's why drivers/media/video/Makefile contains references to
> zoran.o, while zoran.c was ditched?
zoran.c moved, because zoran.o is the output name of the module itself
-
To unsubscribe from this list: send the line "unsubscribe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
Alan Cox writes:
| Adding a bloated interpreter for an obscure, misdesigned bios hardware
| description language is simply not my idea of progress.
Pardon me for butting in, but perhaps this is relevant..
On Mon, 16 Apr 2001, Alan Cox wrote:
> o Fix the Zoran driver build (me)
> | This is still not up to date with the master copy
> | that is intentional - first things first.
Probably that's why drivers/media/video/Makefile contains references to
zoran.o, while
Em Mon, Apr 16, 2001 at 05:16:58PM +0100, Alan Cox escreveu:
> > gcc -D__KERNEL__ -I/tmp/build-kernel/usr/src/linux-2.4.3ac7/include -Wall
>-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
>-mpreferred-stack-boundary=2 -march=i586 -DMODULE -DMODVERSIONS -include
>/tmp/bui
> I tried it on my dual P3 box with the VIA chipset and I'm definitely
> getting timeouts for the USB devices. Booting with "noapic" resolves the
> problem for me. Output of lspci for the VIA stuff is:
Thats an unrelated problem. The BIOS on the tyan tiger is broken
>
-
To unsubscribe from thi
> From: Chris Meadors [mailto:[EMAIL PROTECTED]]
> I saw no mention of the ACPI idle problem I see on my Athlons. Is the
> acpi=no-idle work around the perminate fix?
Fixed. I will be submitting a big ACPI patch to Linus & Alan very soon.
Regards -- Andy
-
To unsubscribe from this list: send t
Alan Cox wrote:
> VIA users should test this kernel carefully. It has what are supposed to be
> the right fixes for the VIA hardware bugs. Obviously the right fixes are not
> as tested as the deduced ones.
>
> 2.4.3-ac7
> o Updated VIA quirk handling for the chipset (Andre Hedrick,
>
On Mon, 16 Apr 2001, Alan Cox wrote:
> > gcc -D__KERNEL__ -I/tmp/build-kernel/usr/src/linux-2.4.3ac7/include
> -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing
> -pipe -mpreferred-stack-boundary=2 -march=i586 -DMODULE -DMODVERSIONS
> -include
> /tmp/build-kernel/usr/src/lin
> gcc -D__KERNEL__ -I/tmp/build-kernel/usr/src/linux-2.4.3ac7/include -Wall
>-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
>-mpreferred-stack-boundary=2 -march=i586 -DMODULE -DMODVERSIONS -include
>/tmp/build-kernel/usr/src/linux-2.4.3ac7/include/linux/modversions.h
=== Cut ===
make[3]: Entering directory `/tmp/build-kernel/usr/src/linux-2.4.3ac7/drivers/net/wan'
ld -m elf_i386 -r -o wanpipe.o sdlamain.o sdla_ft1.o sdla_x25.o sdla_fr.o sdla_chdlc.o
sdla_ppp.o wanpipe_multppp.o
gcc -D__KERNEL__ -I/tmp/build-kernel/usr/src/linux-2.4.3ac7/include -Wall
-Wstric
> On Mon, 16 Apr 2001, Alan Cox wrote:
> > VIA users should test this kernel carefully. It has what are supposed to be
> > the right fixes for the VIA hardware bugs. Obviously the right fixes are not
> > as tested as the deduced ones.
>
> I saw no mention of the ACPI idle problem I see on my Athl
On Mon, 16 Apr 2001, Alan Cox wrote:
> VIA users should test this kernel carefully. It has what are supposed to be
> the right fixes for the VIA hardware bugs. Obviously the right fixes are not
> as tested as the deduced ones.
I saw no mention of the ACPI idle problem I see on my Athlons. Is th
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
VIA users should test this kernel carefully. It has what are supposed to be
the right fixes for the VIA hardware bugs. Obviously
21 matches
Mail list logo
