[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: pre-release 2.6.11-0.1 debian/powerpc kernel.

On Thu, Mar 10, 2005 at 10:40:32AM +0100, Michael Schmitz wrote:
> > >   I tried "showkey -s" on the console.  Pressing "fn" does not result
> > >   in any output.
> >
> > It has never emitted any scan code on any Mac with an
> > ADB keyboard. Its state is kept internally.
> >
> > What I'd like, but I don't have a new PowerBook, is to
> > make fn modify the trackpad behaviour to a scrollwheel.
> > There is a small MacOS X application that does
> > this and it's quite nifty.
> Tricky to do, if the fn key state is kept internally to the PMU/ADB
> hardware. What does the OSX app do, precisely?

Its state is kept in ther kernel, look at drivers/macintosh/adbhid.c,
it even affects the linux keycode for the Delete key.

> > > 	radeonfb (0000:00:10.0): Invalid ROM signature 303 should be0xaa55
> >
> > Some overeager PC-only hacker that believes that god intended
> > all processors to be x86-compatible :-(. 0303 is Open Firmware
> > signature, meaning that the ROM contains FCode AFAIR; 0xaa55 is
> > for PC Bioses, implying binary x86 code.
> It's been reporting that for ages - just means 'no BIOS' for us, unless
> someone writes a Forth interpreter for X to use.
> > > 	ohci1394: fw-host0: Unexpected PCI resource length of 1000!
> >
> > No idea either, but I'd bet that it is harmless.
> I'm seeing that all the time (and weirder stuff) and it doesn't keep the
> fw disk from working.

>From drivers/ieee1394/ohci1394.c:

	/* We hardwire the MMIO length, since some CardBus adaptors
	 * fail to report the right length.  Anyway, the ohci spec
	 * clearly says it's 2kb, so this shouldn't be a problem. */
	ohci_base = pci_resource_start(dev, 0);
	if (pci_resource_len(dev, 0) != OHCI1394_REGISTER_SIZE)
		PRINT(KERN_WARNING, "Unexpected PCI resource length of %lx!",
		      pci_resource_len(dev, 0));

but nothing in the PCI specification prohibits a device from requesting 
4kb even is only 2kb are used.

I've seen devices asking for 64kB when they actually need only 4kB, 
that's a bit excessive but still allowed. Now where the fun started
with older kernels was that some versions of that chip had two base 
registers, one in the MMIO space, one in the I/O space and you tried
to allocate the I/O part in the 64kB I/O space on x86.

Coming back to the problem at hand, I don't know what the buggy 
CarbBus adapters report, but I'd say that changing the test to 
accept 2kb to 4kb or even 8kb should be safe and silence the warning.


Reply to: