OH, THAT ___"WALLSTREET TICK'EN, I DO LOVE YOU SO MUCH (PLEASE SEND A
SHOUT OUT OF SOME STRENGTH TO THE PEACE OFFICERS IN REDWOOD CITY SHERIFFS
DEPT. AND MUCH LOVE TOOTH THE DALY CITY POLICE AND SAN FRAN
FRANCISCO,COLMA,BRISBANE,SOUTHCITY,BROADMOOR WESTMOORHIGHSCCHOOLTHOONTONTON
BEACH REBUI
Hi all,
I have a bug here, and I was wondering if anyone could confirm
that it happens to them, too before I go hacking source.
I have pmud 0.10-1 installed, and I just noticed something strange.
When the system sleeps (closed cover, or running /sbin/snooze), I
lose Ethernet. *** But only when
On Mon, Jun 10, 2002 at 12:20:28PM +1000, Timothy Bateman wrote:
>
> I've just installed Debian Woody for PowerPC and I have some dependency
> problems with apt-get. After the base install, when Debian booted I
> selected a fairly minimal set to just get the machine up and going, such
> as C/C++
I've just installed Debian Woody for PowerPC and I have some dependency
problems with apt-get. After the base install, when Debian booted I
selected a fairly minimal set to just get the machine up and going, such
as C/C++ so I can rebuild a kernel and XWindow System.
I used a local mirror as m
Inside the driver I consistently use the address
from pci_resource_start(dev, 0) + PCI_BASE_ADDRESS_0.
That's the origin of the 0x10 offset in the io_port compared to
the resource start value.
Apart from this I see your point and it is basically correct.
I'm thinking about using inb() in read_p
Hi Ballabio,
On 9 Jun, this message from [EMAIL PROTECTED] echoed through cyberspace:
> If lspci reports I/O address 0x1400 you must use io_port=0x1410,
> the additional 0x10 is the io_base_address_0 offset.
Are you sure that this is the reason for the offset? io_base_address_0
is at offset 0x
On Sun, 2002-06-09 at 15:58, Håvard Skinnemoen wrote:
>
> I recently installed Debian on a PowerBook G4 667 (3. generation, with
> DVI and Radeon M7), and I ran into some similar problems. After a week
> or so searching for information and trying various things, I got X
> working. Basically, this
On Sun, Jun 09, 2002 at 01:29:02PM +0200, [EMAIL PROTECTED] wrote:
> Domenica, Giugno 9, 2002, alle 12:41 PM, Benjamin Herrenschmidt ha
> scritto:
>
> This is probably due to the radeonfb driver trying to set an incorrect
> mode on your LCD. This should have been fixed in recent versions of the
Domenica, Giugno 9, 2002, alle 12:41 PM, Benjamin Herrenschmidt ha scritto:
This is probably due to the radeonfb driver trying to set an incorrect
mode on your LCD. This should have been fixed in recent versions of the
driver in my rsync tree, which is why I'm asking you to test.
As soon as possi
>I have found that when installing I must use the safe mode, and I had to
>add video=ofonly to my yaboot.conf, otherise the screen is corrupted and
>then gradually fades away and nothing more happens.
This is probably due to the radeonfb driver trying to set an incorrect
mode on your LCD. This sho
I have found that when installing I must use the safe mode, and I had to
add video=ofonly to my yaboot.conf, otherise the screen is corrupted and
then gradually fades away and nothing more happens.
Tim
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Cont
>The problem may simply be that you need the right kernel option to make
>it talk to your graphics card. Have you tried any of "novideo",
>"video=ofonly", or "video=nofb" as command line arguments to Linux, or
>Debian, or /vmlinux or whatever you invoke the kernel as?
You can also try compiling a
12 matches
Mail list logo
