On Fri, 2003-08-15 at 20:13, Jan Rychter wrote:
> From http://news.com.com/2100-1006-993896.html:
>
> Intel plans Linux support for Centrino
>
> Intel is working on Linux support for Centrino, its package of chips for
> mobile computers with wireless networking abilities, but the company
> hasn't yet decided how or when to release it.
>
> That was on March 24, 2003.
>
> Well, that was almost 5 months ago. So I figured I'd ask if there's any
> progress -- so far the built-in wireless in my notebook still doesn't
> work with Linux and the machine is monstrously power-hungry because
> Linux doesn't scale the CPU frequency.
>
> I know there are some Intel people on the list -- perhaps someone can
> comment?
Status:
Wlan - not supported
CPU - CPUfreq (-ac tree) and ACPI throttling work just fine. I've got my
Pentium M running at 600 MHz when the Power Supply is plugged out.
Regards,
Martin List-Petersen
martin at list-petersen dot se
--
for ARTIFICIAL FLAVORING!!
On Fri, 2003-08-15 at 11:13, Jan Rychter wrote:
> Well, that was almost 5 months ago. So I figured I'd ask if there's any
> progress -- so far the built-in wireless in my notebook still doesn't
> work with Linux and the machine is monstrously power-hungry because
> Linux doesn't scale the CPU frequency.
Intel shows no inclination to release Centrino wireless drivers for
Linux. There have been vague insinuations that this is due to excessive
software controllability, but no public explanations have been given,
beyond "we're not doing it at this moment".
If you want built-in wireless in the nearish term, you'll have to get a
supported MiniPCI card and replace your Centrino card.
As far as CPU is concerned, if you're using recent 2.5 or 2.6 kernels,
there's Pentium M support in cpufreq. Jeremy Fitzhardinge has written a
userspace daemon that varies the Pentium M CPU frequency in response to
load.
<b
On Fri, Aug 15, 2003 at 11:13:09AM -0700, Jan Rychter wrote:
> From http://news.com.com/2100-1006-993896.html:
>
> Intel plans Linux support for Centrino
>
> Intel is working on Linux support for Centrino, its package of chips for
> mobile computers with wireless networking abilities, but the company
> hasn't yet decided how or when to release it.
>
> That was on March 24, 2003.
>
> Well, that was almost 5 months ago. So I figured I'd ask if there's any
> progress -- so far the built-in wireless in my notebook still doesn't
> work with Linux and the machine is monstrously power-hungry because
> Linux doesn't scale the CPU frequency.
CPU frequency scaling is supported now at least. (Though you'll need
-ac for 2.4, or 2.6). Wireless is still unsupported AFAIK.
Dave
--
Dave Jones http://www.codemonkey.org.uk
Bryan O'Sullivan wrote:
>If you want built-in wireless in the nearish term, you'll have to get a
>supported MiniPCI card and replace your Centrino card.
>
>
>
Got a list of supported good working cards?
>As far as CPU is concerned, if you're using recent 2.5 or 2.6 kernels,
>there's Pentium M support in cpufreq. Jeremy Fitzhardinge has written a
>userspace daemon that varies the Pentium M CPU frequency in response to
>load.
>
>
Can you please point me to this daemon?
Regards
--
Christian Axelsson
[email protected]
Christian Axelsson wrote :
>
> Got a list of supported good working cards?
Google -> Linux Wireless
My Linux Wireless Howto contains pretty much the latest info
on the subject, so I doubt you would not find the info you are looking
for...
Regards,
Jean
On Fri, 15 Aug 2003 22:24:26 +0200 Christian Axelsson <[email protected]> wrote:
| Bryan O'Sullivan wrote:
|
| >If you want built-in wireless in the nearish term, you'll have to get a
| >supported MiniPCI card and replace your Centrino card.
| >
| >
| >
| Got a list of supported good working cards?
Mini-PCI or CardBus?
I think that some people just add a CardBus wireless card.
| >As far as CPU is concerned, if you're using recent 2.5 or 2.6 kernels,
| >there's Pentium M support in cpufreq. Jeremy Fitzhardinge has written a
| >userspace daemon that varies the Pentium M CPU frequency in response to
| >load.
| >
| >
| Can you please point me to this daemon?
http://www.goop.org/~jeremy/speedfreq/
--
~Randy
I thought that this line of argument was due to FCC regulations. That
is, software settings would allow the hardware to violate frequency or
strength-of-signal limitations set by government regulations. This is
only from memory, so feel free to correct.
-Brandon
Bryan O'Sullivan wrote:
>On Fri, 2003-08-15 at 11:13, Jan Rychter wrote:
>
>
>>Well, that was almost 5 months ago. So I figured I'd ask if there's any
>>progress -- so far the built-in wireless in my notebook still doesn't
>>work with Linux and the machine is monstrously power-hungry because
>>Linux doesn't scale the CPU frequency.
>>
>>
>
>Intel shows no inclination to release Centrino wireless drivers for
>Linux. There have been vague insinuations that this is due to excessive
>software controllability, but no public explanations have been given,
>beyond "we're not doing it at this moment".
>
>If you want built-in wireless in the nearish term, you'll have to get a
>supported MiniPCI card and replace your Centrino card.
>
>As far as CPU is concerned, if you're using recent 2.5 or 2.6 kernels,
>there's Pentium M support in cpufreq. Jeremy Fitzhardinge has written a
>userspace daemon that varies the Pentium M CPU frequency in response to
>load.
>
On Fri, 2003-08-15 at 13:24, Christian Axelsson wrote:
> Got a list of supported good working cards?
There's a Dell TrueMobile card that uses the Orinoco chipset. If you're
feeling like life is too boring, there are cards based on the newer
Intersil dual 802.11b/g chipsets available, too, and though I haven't
checked into the shape of the drivers, I know they're under active
development.
<b
On Fri, 2003-08-15 at 13:35, Jan Rychter wrote:
> I keep dreaming about the day when I'll be able to have a modern laptop
> with a stable Linux kernel. As for now, it has taken me (on one of my
> laptops) about 1.5 years to get to a point where 2.4 works, most of my
> hardware works, and software suspend (pretty much a requirement for
> laptops) works. I'm not about to give that up easily, so I'm not that
> eager to jump to 2.5/2.6.
Can't say that's been my experience. I bought a new Thinkpad X31 the
other day, and it's already running 2.6.0-test3. Suspend works, all's
happy.
> 1. Will cpufreq make it into the standard 2.4 kernels?
Highly unlikely.
> 3. Where does one get 2.4 cpufreq?
There are snapshots available at http://www.linux.org.uk (hint: Google for
"cpufreq"), or in -ac. See the cpufreq mailing list archives for a
bunch of daemons that control this stuff in various semi-cooked ways.
<b
On Fri, 2003-08-15 at 22:55, Bryan O'Sullivan wrote:
> On Fri, 2003-08-15 at 13:24, Christian Axelsson wrote:
>
> > Got a list of supported good working cards?
>
> There's a Dell TrueMobile card that uses the Orinoco chipset. If you're
> feeling like life is too boring, there are cards based on the newer
> Intersil dual 802.11b/g chipsets available, too, and though I haven't
> checked into the shape of the drivers, I know they're under active
> development.
The Dell TrueMobile 1150 series are Agere/Orinoco/Hermes based (MiniPCI
and PC-Card available). All other Dell TrueMobile cards are Broadcom
based and have no Linux driver support either.
There are also MiniPCI, PC-Card, USB adapters with 802.11a/b/g and Linux
drivers available: http://sf.net/projects/madwifi
These are based on the Ateros chipset, which also is around in some OEM
products.
> > > As far as CPU is concerned, if you're using recent 2.5 or 2.6
> > > kernels, there's Pentium M support in cpufreq. Jeremy
> > > Fitzhardinge has written a userspace daemon that varies the
> > > Pentium M CPU frequency in response to
> > > load.
> >
> > Can you please point me to this daemon?
http://sf.net/projects/cpufreqd
Regards,
Martin List-Petersen
martin at list-petersen dot se
--
"An idealist is one who, on noticing that a rose smells better than a
cabbage, concludes that it will also make better soup." - H.L. Mencken
>> Can you please point me to this daemon?
>
> http://www.goop.org/~jeremy/speedfreq/
Or http://mnm.uib.es/~gallir/cpudyn/
if you want something very simple but effective and tested in almost every
processor (it works in 2.6.0 and 2.4 plus cpufreq patches, for example -ac
tree).
--
ricardo galli GPG id C8114D34
http://mnm.uib.es/~gallir/
On Fri, 15 Aug 2003 16:46:19 -0400
Brandon Stewart <[email protected]> wrote:
> I thought that this line of argument was due to FCC regulations. That
> is, software settings would allow the hardware to violate frequency or
> strength-of-signal limitations set by government regulations. This is
> only from memory, so feel free to correct.
I think I have read in an earlier thread something the like.
But I cannot understand how this can be logically linked to releasing docs. If
all companies would follow this thought e.g. Siemens would never have released
the docs for ISDN chipsets and therefore no ISDN drivers would be in the
kernel. I'd rather say someone with money is afraid ...
Mobile equipment like laptops is a booming market and it all turns around
shares...
There is another point about this topic. How does M$ (with their centrino
drivers) guarantee that no user tries to switch on the addtional ETSI
frequencies? I doubt this is possible at all. Of course you can simply ignore
that there are ETSI frequencies which basically means to ignore the
overwhelming part of europe and their respective regulation.
Some political explosives are in this thread ...
Regards,
Stephan
> [[email protected]]
>
> I thought that this line of argument was due to FCC regulations. That
> is, software settings would allow the hardware to violate frequency or
> strength-of-signal limitations set by government regulations. This is
> only from memory, so feel free to correct.
As though one couldn't do all this with other wireless hw...
--
Tomas Szepe <[email protected]>
On Fri, Aug 15, 2003 at 01:35:17PM -0700, Jan Rychter wrote:
> 1. Will cpufreq make it into the standard 2.4 kernels?
We asked Marcelo if he wanted it for 2.4.23, and he didn't object,
so time permitting, it could show up there next time.
> 2. If not, will Alan incorporate swsusp into -ac kernels? (given that
> -ac kernels seem to have cpufreq included)
Very unlikely.
> 3. Where does one get 2.4 cpufreq?
Normally http://www.codemonkey.org.uk/projects/cpufreq
However the box hosting that website dies within a few hours if I restart
apache (Its incredibly underpowered for the load it gets), so plans are
afoot to move it to something that can handle it. Should be back up
(for good this time hopefully) within a week or so.
Dave
--
Dave Jones http://www.codemonkey.org.uk
On Gwe, 2003-08-15 at 21:35, Jan Rychter wrote:
> Question time:
>
> 1. Will cpufreq make it into the standard 2.4 kernels?
In time maybe - up to Marcelo.
> 2. If not, will Alan incorporate swsusp into -ac kernels? (given that
> -ac kernels seem to have cpufreq included)
Not in its current form. To do the job well swsuspend needs the kernel
device model.
> > > Got a list of supported good working cards?
> >
> > There's a Dell TrueMobile card that uses the Orinoco chipset. If you're
> > feeling like life is too boring, there are cards based on the newer
> > Intersil dual 802.11b/g chipsets available, too, and though I haven't
> > checked into the shape of the drivers, I know they're under active
> > development.
>
> The Dell TrueMobile 1150 series are Agere/Orinoco/Hermes based (MiniPCI
> and PC-Card available). All other Dell TrueMobile cards are Broadcom
> based and have no Linux driver support either.
>
> There are also MiniPCI, PC-Card, USB adapters with 802.11a/b/g and Linux
> drivers available: http://sf.net/projects/madwifi
That driver contains a binary-only part.
<quote>
The ath_hal module contains the Atheros Hardware Access Layer (HAL).
This code manages much of the chip-specific operation of the driver.
The HAL is provided in a binary-only form in order to comply with FCC
regulations. In particular, a radio transmitter can only be operated at
power levels and on frequency channels for which it is approved. The FCC
requires that a software-defined radio cannot be configured by a user
to operate outside the approved power levels and frequency channels.
This makes it difficult to open-source code that enforces limits on
the power levels, frequency channels and other parameters of the radio
transmitter. See
http://ftp.fcc.gov/Bureaus/Engineering_Technology/Orders/2001/fcc01264.pdf
for the specific FCC regulation. Because the module is provided in a
binary-only form it is marked "Proprietary"; this means when you load
it you will see messages that your system is now "tainted".
</quote>
US was a free country. It gets worse by the day.
--
vda
insecure wrote:
> This makes it difficult to open-source code that enforces limits on
> the power levels, frequency channels and other parameters of the radio
> transmitter. See
>
> http://ftp.fcc.gov/Bureaus/Engineering_Technology/Orders/2001/fcc01264.pdf
>
> for the specific FCC regulation.
I have just read that FCC regulation.
It doesn't prevent open-sourcing the code. It does require that each
software-defined radio must have some kind of authentication mechanism
to ensure that unapproved software cannot be loaded on to the device.
It seems to me that distributing a binary, which is easily modified by
users, (as proven by all the game patches and application cracks out
there), does _not_ satisfy the FCC regulation.
The only way to satisfy the regulation is to have an authentication
mechanism of some kind, so that the radio will not operate with
unapproved software.
If Intel have not implemented an authentication mechanism, then they
are not compliance with the FCC regulation as I read it because it
won't be long before some enterprising user patches the firmware and
makes the radio behave in an unapproved, possibly RF unsafe manner.
If Intel have implement such a mechanism, then regulation is no excuse
for them to not release the source code.
-- Jamie
Jan Rychter wrote:
> >>>>> "Stephan" == Stephan von Krawczynski <[email protected]>:
> Stephan> I think I have read in an earlier thread something the like.
> Stephan> But I cannot understand how this can be logically linked to
> Stephan> releasing docs. If all companies would follow this thought
> Stephan> e.g. Siemens would never have released the docs for ISDN
> Stephan> chipsets and therefore no ISDN drivers would be in the
> Stephan> kernel. I'd rather say someone with money is afraid ...
>
> Yes, that sounds rather ridiculous. Sooner or later someone is going to
> reverse-engineer the thing, so not releasing drivers or specs just
> delays this moment. If there's a manager at Intel that thinks this way,
> he doesn't understand much about security.
Let's be fair to Intel for a moment.
With hardware radios, anyone can open it up, fiddle with electronics,
and make it do something illegal, possibly dangerous. Manufacturers
aren't required to make them impregnable!
All manufacturers have to do is not put any knobs on the front which
can make the radio do unapproved things.
Folk are allowed to fiddle with radio electronics, with care, as long
as they get themselves a radio license and stick to the rules.
They can even sell an altered device, if they take it through the FCC
approval process.
With a software radio, it's analagous. The manufacturer doesn't have
to make it _impossible_ to reprogram, they just have to make it hard
enough that ordinary users won't do it.
Releasing the source code may or may not result in ordinary users
reprograming their radios in harmful ways. Though, you can imagine
people would circulate patches to boost the power in no time.
At least there is some hope for the expert hobbyist: they _can_
reverse engineer the device. It is good that this is possible.
If Intel build a crypto-based authentication mechanism into their
software radios, then there is no hope for the amateur radio hobbyist
to fiddle with their radios.
So, really, Intel has done the amateur radio community a favour by
leaving the tantalising possibility of reverse engineering the driver,
compared with a DRM solution which totally prevents even expert tinkering.
-- Jamie
On Sad, 2003-08-16 at 20:58, Jan Rychter wrote
> Unfortunately, we live in a world of compromises. If I were RedHat, I'd
> stay real quiet and play nice in order to get Intel's cooperation on
> servers (which brings revenue) instead of fighting for laptops (which is
> a niche market for Linux, in a chicken-and-egg sort of way).
Vendors are beginning to make commitments to Linux support on some
laptops, in addition Intel and ATI in paticular have been doing nice
things to the laptop chipset market by drastically shrinking the number
of variants. Centrino in some ways is a help as is the ATI+ALI setup
used by all the nice mobile Athlon laptops - now when we get one working
the rest tend to just follow.
Alan
On Fri, 2003-08-15 at 21:13, Jan Rychter wrote:
> Well, that was almost 5 months ago. So I figured I'd ask if there's any
> progress -- so far the built-in wireless in my notebook still doesn't
> work with Linux and the machine is monstrously power-hungry because
> Linux doesn't scale the CPU frequency.
>
> I know there are some Intel people on the list -- perhaps someone can
> comment?
I have made a patch set for my laptop which you may like to try. It
mainly contains stuff from -aa and -ac kernels and various other pieces.
See http://www.sonarnerd.net/projects/linux/
With this and my backport of latest XFree86 ATI drivers I have Linux
running nicely on my Compaq Evo N1015v and N1020v laptops. At least it
_subjectively_ warms up less and consumes less power under Linux
compared to Windows XP.
--
Jussi Laako <[email protected]>
Brandon Stewart wrote:
> I thought that this line of argument was due to FCC regulations. That
> is, software settings would allow the hardware to violate frequency or
> strength-of-signal limitations set by government regulations. This is
> only from memory, so feel free to correct.
This does not in any way prevent them from releasing a driver,
open or closed source. It merely makes tampering with
the driver illegal.
And it doesn't prevent them from merely releasing programming specs
if they're too cheap to make a driver either. Of course whoever
programs the driver will then have to get approved
by the bureaucracy himself, or leave it to some linux vendor
before it can be (legally) used.
No driver _and_ no specs means they aren't supporting linux
at the moment.
Helge Hafting
On Saturday 16 August 2003 11:12, Alan Cox wrote:
> On Gwe, 2003-08-15 at 21:35, Jan Rychter wrote:
> > Question time:
> >
> > 1. Will cpufreq make it into the standard 2.4 kernels?
>
> In time maybe - up to Marcelo.
>
> > 2. If not, will Alan incorporate swsusp into -ac kernels? (given that
> > -ac kernels seem to have cpufreq included)
>
> Not in its current form. To do the job well swsuspend needs the kernel
> device model.
I've tried it a few times on 2.6.0-test3 right after the system comes up and I
log in to text mode, and the sucker spits out exactly one line of text
(something like "Suspending processes:") and hangs with the cursor right
after the semicolon. After about a minute I hit ctrl-scroll lock, but
everything except the suspend thread (which was waiting in some kind of yield
for other threads to do something) scrolled off the top and I don't know how
to cursor up to see it (or get it to not scroll off).
I'd be happy to test someting better. APM suspend doesn't work on my new
thinkpad, so it's swsusp or nothing. Currently, it's "shutdown -h now",
which has some obvious deficiencies...
Rob
>>>>> "Brandon" == Brandon Stewart <[email protected]> writes:
>>>>> "Helge" == Helge Hafting <[email protected]> writes:
Brandon> I thought that this line of argument was due to FCC
Brandon> regulations. That is, software settings would allow the
Brandon> hardware to violate frequency or strength-of-signal
Brandon> limitations set by government regulations. This is only
Brandon> from memory, so feel free to correct.
Helge> This does not in any way prevent them from releasing a driver,
Helge> open or closed source. It merely makes tampering with the
Helge> driver illegal.
Unless of course it can be programmed to listen in on the AMPS cell
phone band(s). In that case it could arguably be a felony for them to
release the programming info.... (Stupid law, but it has been
enforced rather obsessively....)
-JimC
James H. Cloos Jr. wrote:
> Helge> This does not in any way prevent them from releasing a driver,
> Helge> open or closed source. It merely makes tampering with the
> Helge> driver illegal.
>
> Unless of course it can be programmed to listen in on the AMPS cell
> phone band(s). In that case it could arguably be a felony for them to
> release the programming info.... (Stupid law, but it has been
> enforced rather obsessively....)
How is that different from selling a radio which can be retuned by
opening it up and changing some resistors and capacitors?
-- Jamie
On Wed, 2003-08-20 at 02:55, Jamie Lokier wrote:
> James H. Cloos Jr. wrote:
> > Helge> This does not in any way prevent them from releasing a driver,
> > Helge> open or closed source. It merely makes tampering with the
> > Helge> driver illegal.
> >
> > Unless of course it can be programmed to listen in on the AMPS cell
> > phone band(s). In that case it could arguably be a felony for them to
> > release the programming info.... (Stupid law, but it has been
> > enforced rather obsessively....)
>
> How is that different from selling a radio which can be retuned by
> opening it up and changing some resistors and capacitors?
arguably a patch is much easier to implement and distribute where as
changing some resistors and capacitors would take more technical
knowledge, although I don't know where the stands on that.
>
> -- Jamie
> -
> 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://www.tux.org/lkml/