Hi!
> There as been a fair amount of consensus that calling
> device_suspend(...) in the reboot path was inappropriate now, because
> the device suspend code was too immature. With this latest
> piece of evidence it seems to me that introducing device_suspend(...)
> in kernel_power_off, kernel_h
Early in the 2.6.13 process my kexec related patches were introduced
into the reboot path, and under the rule you touch it you fix it
it I have been involved in tracking quite a few regressions
on the reboot path.
Recently with Benjamin Herrenschmidt's removal of
device_suppend(PMSG_SUPPEND) from
Hi!
I got frontlight to work, wow. Patch is extremely ugly, and I have a
small problem? How do I do this properly? I need locomo_writel() to
manipulate frontlight settings, but that only seems available in
locomo.c. Putting frontlight support there is certainly possible, but
looks ugly to me...
On So 30-07-05 10:26:56, Russell King wrote:
> On Mon, Jul 25, 2005 at 08:22:42AM +0200, Pavel Machek wrote:
> > I replaced sharp functions with ucb_1x00 functions this way; I hope I
> > did not mess it up.
> >
> > diff --git a/arch/arm/mach-sa1100/battery-collie.c
> > b/arch/arm/mach-sa1100/batt
On Mon, Jul 25, 2005 at 08:22:42AM +0200, Pavel Machek wrote:
> I replaced sharp functions with ucb_1x00 functions this way; I hope I
> did not mess it up.
>
> diff --git a/arch/arm/mach-sa1100/battery-collie.c
> b/arch/arm/mach-sa1100/battery-collie.c
> --- a/arch/arm/mach-sa1100/battery-collie.
Hi!
> I have similar problems with the corgi battery driver which is probably
> even more of a mess than this. My conclusion is the whole lot needs
> rewriting in a nice fashion before it can be included in mainline. My
> work so far on the corgi code is here:
>
> http://www.rpsys.net/openzaurus/
Hi!
> > #defineSCP_REG_MCR SCP_REG(SCP_MCR)
> > #defineSCP_REG_CDR SCP_REG(SCP_CDR)
> > #defineSCP_REG_CSR SCP_REG(SCP_CSR)
> > #defineSCP_REG_CPR SCP_REG(SCP_CPR)
> > #defineSCP_REG_CCR SCP_REG(SCP_CCR)
> > #defineSCP_REG_IRR
On Mon, 2005-07-25 at 07:46 +0200, Pavel Machek wrote:
> I took battery charging code from sharp and placed it in
> arch/arm/mach-sa1100/battery-collie.c (hope that's good place...). It
> still does not link, and will need complete rewrite, but... If you
> have done this already please let me know.
Hi!
I took battery charging code from sharp and placed it in
arch/arm/mach-sa1100/battery-collie.c (hope that's good place...). It
still does not link, and will need complete rewrite, but... If you
have done this already please let me know.
/*
* Battery routines for collie (Sharp Zaurus sl-5500)
Hi!
> I took battery charging code from sharp and placed it in
> arch/arm/mach-sa1100/battery-collie.c (hope that's good place...). It
> still does not link, and will need complete rewrite, but... If you
> have done this already please let me know.
I replaced sharp functions with ucb_1x00 functio
Hi!
First, sorry about the so-so topic for the kernel developers...but still
there are such things inside :)
Currently I am investigating how "they" divide those polynomials and
which possibilities exists to use SIMD for such calculations. I have
found several papers about how to do it with Alti
I tried 2.4.5-ac16 on my Asus A7A266 w/ Athlon because the fixnotes
sounded like it might address the simplex vs. DMA problem that I
reported a while back, but I get a kernel panic early in the boot
sequence every time I try to boot.
FYI, 2.4.5-ac14 boots and runs OK, except for the disabled
On Thu, Jun 14, 2001 at 01:33:53PM +0200, Anders Peter Fugmann wrote:
> Great to hear, but I cannot find anything that backs it up.
> I really want to see the final RFC.
>
> Perhaps you could send me an URL pointing to it?
Usually takes a few days until the RFC editor will announce and
publish
Hi Jamal
Great to hear, but I cannot find anything that backs it up.
I really want to see the final RFC.
Perhaps you could send me an URL pointing to it?
TIA
Anders Fugmann
jamal wrote:
>
> The IESG approved ECN as a proposed standard on the 12th of June.
> That means as of now, anyone block
The IESG approved ECN as a proposed standard on the 12th of June.
That means as of now, anyone blocking ECN bits is considered to be
blaspheming.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
On Tue, May 22, 2001 at 06:02:12PM +0200, Dr. Michael Weller wrote:
> It's an interesting experiment actually: Is the linux community powerful
> enough to force vendors/people to fix their products and deploy updates to
> comply to standards or can they just ignore it.
largely the vendors have fi
sender.
This message is just a FYI. Please send an email to [EMAIL PROTECTED]
if you have further concerns.
Thanks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/maj
On 22 May 2001, Michael Peddemors wrote:
> H.. In principle this sounds good, but...
>
> This doesn't seem to be in best interest.. Taking it to the extreme,
> noone should code the linux kernel for buggy bios's, cards etc anymore
> either.. We should all tell em to upgrade their hardware?
H.. In principle this sounds good, but...
This doesn't seem to be in best interest.. Taking it to the extreme,
noone should code the linux kernel for buggy bios's, cards etc anymore
either.. We should all tell em to upgrade their hardware?
Almost every software application has made allowanc
vger.kernel.org is now ECN enabled.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://w
Hi!
Here it how it looks just now. This is work in progress, but feel free
to apply. [You may want to restructure it somehow, move it into
different place maybe, and call its init from convient place].
Oh, and "ACPI_OK" should be killed. It is too easy to write it instead
of AE_OK.
FYI, a copy...
--- Start of forwarded message ---
From: Ulrich Windl <[EMAIL PROTECTED]>
Newsgroups: comp.protocols.time.ntp
Subject: announce: Linux PPS support for Kernel 2.4.2
Date: 13 Mar 2001 08:04:56 +0100
Organization: University of Regensburg, Germany
Message-ID: &
So that's why I'm getting duplicate posting on some meesages. Thanks Dave.
Matthew.
- Original Message -
From: David S. Miller <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: Linux Kernel Mailing List <[EMAIL PROTECTED]>
Sent: Wednesday, February 07, 2
[EMAIL PROTECTED] writes:
>
> Every mail I'm sending to l-k gets me a reply from
> [EMAIL PROTECTED] saying it's
> awaiting moderator approval.
>
> ISTR this happened last week also with another domain ?
Yes, and those bozos ([EMAIL PROTECTED])
keep resubscribing too. I've removed them
Every mail I'm sending to l-k gets me a reply from
[EMAIL PROTECTED] saying it's
awaiting moderator approval.
ISTR this happened last week also with another domain ?
regards,
Dave.
--
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs
-
To unsubscribe from this list: send the line
Hi!
I played a bit with acpi on my toshiba, and got following figures
(toshiba satellite 4030cdt):
system powered on, disk spinning, backlight on, low brightness 12.8W
high brigtness +0.8W
no backlight
Title: RE: fyi megaraid problems
I've compiled the 2.2.18 and 2.4.0 kernels with the latest megaraid driver (1.14b)
and they work well. You should also upgrade your firmware to L148 (bios 3.11).
I think the firmware revision depends on which model card you have, I have the
1600 Elite.
don't know if this has been covered/studied
datapoints I've run across re the megaraid
(scsi raid driver, american megatrends)
box: Dell PowerEdge 2300, 2 cpus, 1G RAM
hard drive setup as single drive via raid
controller
RH6.1, compiled 2.2.13, megaraid works!
RH7.0 install/upgrade breaks on
201 - 228 of 228 matches
Mail list logo
