Linux 2.6.3-rc4

Linux 2.6.3-rc4

[Linus Torvalds]

Ok,
 I'm planning on doing the final 2.6.3 tomorrow, so please test this 
final -rc.

Most notably, this should support ppc/ppc64 out-of-the-box, complete with
G5 support (64-bit). Special thanks to BenH who made sure the new radeonfb
driver works on a wide variety of hardware (a number of the fixes here
relative to -rc3 was making sure the driver works on regular x86 laptops).

Apart from the radeon updates, there's some IDE oops fixes (and cleanups), 
and a SELinux update.

And yes, document the fact that sparc is no longer f*cked up (both atomics 
and irq save/restore now work the way they always did everywhere else).

		Linus

----

Summary of changes from v2.6.3-rc3 to v2.6.3-rc4
============================================

Andrew Morton:
  o SELinux: context mount support - LSM/FS
  o SELinux: context mount support - NFS
  o SELinux: context mount support - SELinux changes
  o devfs do_mount fix
  o selinux: Allow non-root processes to read selinuxfs enforce node
  o selinux: mark avc_init with __init
  o SELinux: Fix error handling bug
  o ppc32: Fix MPC82xx thinko
  o ppc32: Fix MPC82xx UARTs

Anton Blanchard:
  o fix ppc64 LPAR

Bartlomiej Zolnierkiewicz:
  o fix OOPS on non-DMA IDE hosts with CONFIG_BLK_DEV_IDEDMA=y
  o ide-tape: fix "sleeping function called from invalid context"
  o ide-tape: warn about soon to be removed OnStream support
  o remove ide_dma_{good,bad}_drive from ide_hwif_t
  o remove __ide_dma_count() and ide_hwif_t->ide_dma_count
  o make __ide_dma_off() generic and remove ide_hwif_t->ide_dma_off

Benjamin Herrenschmidt:
  o Remove debug cruft from via-pmu.c driver
  o Fix Oops & warning on PPC in rivafb
  o shield fbdev operations with console semaphore
  o Fix fbdev pixmap locking
  o Update aty128fb video driver
  o fbdev state management
  o fbcon notified of suspend/resume
  o fix radeonfb "noaccel" command line
  o radeonfb: limit ioremap size & debug output
  o Update platinumfb driver
  o Small typo in aty128fb
  o Fix rtasd zombie on PowerMac G5
  o Fix building both old & new radeonfb's
  o Fix ppc compile problem with gcc 3.4

Jeff Garzik:
  o Update mac network drivers

Linus Torvalds:
  o Fix new radeon clock calculation
  o Fix user-visible typo in printk
  o Fix radeonfb to use the proper BIOS reference divider for
    flat-panel displays.
  o Fix link error with RADEON_DEBUG and !RADEON_I2C
  o Revert the dodgy ia64 serial console changeset by Bjorn Helgaas
  o Linux 2.6.3-rc4

Marcel Holtmann:
  o [Bluetooth] Revert reference counting fixes

Peter Osterlund:
  o Missing initialization code for old radeon driver

Rusty Russell:
  o Sparc no longer F*cked Up

Re: Linux 2.6.3-rc4

[Felix Seeger]

On Tuesday 17 February 2004 04:51, Linus Torvalds wrote:
> Ok,
>  I'm planning on doing the final 2.6.3 tomorrow, so please test this
> final -rc.

Hi

Should NForce2 boards also work without patches and with acpi/apic ?
I saw a change in rc3.

It just hangs again, so I switched back to my patched kernel.
But of course this could be another problem, kernel 2.6.2-rc1 is running very 
stable here with the apictack-rd and the ioapic-rd patches.

thanks
Felix

Re: Linux 2.6.3-rc4

[Martin Diehl]

On Mon, 16 Feb 2004, Linus Torvalds wrote:

> Bartlomiej Zolnierkiewicz:
>   o make __ide_dma_off() generic and remove ide_hwif_t->ide_dma_off

doesn't build for me:

drivers/built-in.o(.text+0x3aa33): In function `set_using_dma':
: undefined reference to `__ide_dma_off'
drivers/built-in.o(.text+0x401bc): In function `check_dma_crc':
: undefined reference to `__ide_dma_off'
make: *** [.tmp_vmlinux1] Error 1

relevant .config section below.

Martin

-------------------------

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_IDEDISK_STROKE is not set
# CONFIG_BLK_DEV_IDECS is not set
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_IDE_TASKFILE_IO is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPCI is not set
# CONFIG_IDE_CHIPSETS is not set
# CONFIG_BLK_DEV_IDEDMA is not set
# CONFIG_IDEDMA_AUTO is not set
# CONFIG_DMA_NONPCI is not set
# CONFIG_BLK_DEV_HD is not set

Re: Linux 2.6.3-rc4

[Martin Diehl]

On Tue, 17 Feb 2004, Martin Diehl wrote:

> drivers/built-in.o(.text+0x3aa33): In function `set_using_dma':
> : undefined reference to `__ide_dma_off'
> drivers/built-in.o(.text+0x401bc): In function `check_dma_crc':
> : undefined reference to `__ide_dma_off'
> make: *** [.tmp_vmlinux1] Error 1

FWIW, the patch below solved this, but I'm not sure if it's the correct 
fix.

Martin

-----------------------------

--- linux-2.6.3-rc4/drivers/ide/Makefile	Tue Feb 10 18:14:34 2004
+++ v2.6.3-rc4-md-ob/drivers/ide/Makefile	Tue Feb 17 10:24:46 2004
@@ -14,13 +14,13 @@
 obj-$(CONFIG_BLK_DEV_IDE)		+= pci/
 
 ide-core-y += ide.o ide-default.o ide-io.o ide-iops.o ide-lib.o ide-probe.o \
-	ide-taskfile.o
+	ide-taskfile.o ide-dma.o
 
 ide-core-$(CONFIG_BLK_DEV_CMD640)	+= pci/cmd640.o
 
 # Core IDE code - must come before legacy
 ide-core-$(CONFIG_BLK_DEV_IDEPCI)	+= setup-pci.o
-ide-core-$(CONFIG_BLK_DEV_IDEDMA)	+= ide-dma.o
+# ide-core-$(CONFIG_BLK_DEV_IDEDMA)	+= ide-dma.o
 ide-core-$(CONFIG_BLK_DEV_IDE_TCQ)	+= ide-tcq.o
 ide-core-$(CONFIG_PROC_FS)		+= ide-proc.o
 ide-core-$(CONFIG_BLK_DEV_IDEPNP)	+= ide-pnp.o

Re: Linux 2.6.3-rc4

[Bartlomiej Zolnierkiewicz]

On Tuesday 17 of February 2004 09:54, Martin Diehl wrote:
> On Mon, 16 Feb 2004, Linus Torvalds wrote:
> > Bartlomiej Zolnierkiewicz:
> >   o make __ide_dma_off() generic and remove ide_hwif_t->ide_dma_off
>
> doesn't build for me:
>
> drivers/built-in.o(.text+0x3aa33): In function `set_using_dma':
> : undefined reference to `__ide_dma_off'
>
> drivers/built-in.o(.text+0x401bc): In function `check_dma_crc':
> : undefined reference to `__ide_dma_off'
>
> make: *** [.tmp_vmlinux1] Error 1

Thanks for spotting this, here's a fix (Linus, please apply).
As a bonus it should decrease your kernel's size by a few bytes ;-).

[PATCH] fix build with CONFIG_BLK_DEV_IDEDMA=n (once again)

My "__ide_dma_off()" cleanup uncovered some code that shouldn't be compiled
when CONFIG_BLK_DEV_IDEDMA=n.  Fix it and kill a warning in setup-pci.c.

Noticed by Martin Diehl <lists@mdiehl.de>.

 linux-2.6.3-rc3-root/drivers/ide/ide-iops.c  |    7 ++++---
 linux-2.6.3-rc3-root/drivers/ide/ide.c       |    4 ++++
 linux-2.6.3-rc3-root/drivers/ide/setup-pci.c |    3 +++
 linux-2.6.3-rc3-root/include/linux/ide.h     |    3 +++
 4 files changed, 14 insertions(+), 3 deletions(-)

diff -puN drivers/ide/ide.c~ide_dma_off_fix drivers/ide/ide.c
--- linux-2.6.3-rc3/drivers/ide/ide.c~ide_dma_off_fix	2004-02-17 15:49:14.572521328 +0100
+++ linux-2.6.3-rc3-root/drivers/ide/ide.c	2004-02-17 15:51:12.985519816 +0100
@@ -1320,6 +1320,7 @@ static int set_io_32bit(ide_drive_t *dri
 
 static int set_using_dma (ide_drive_t *drive, int arg)
 {
+#ifdef CONFIG_BLK_DEV_IDEDMA
 	if (!drive->id || !(drive->id->capability & 1))
 		return -EPERM;
 	if (HWIF(drive)->ide_dma_check == NULL)
@@ -1332,6 +1333,9 @@ static int set_using_dma (ide_drive_t *d
 			return -EIO;
 	}
 	return 0;
+#else
+	return -EPERM;
+#endif
 }
 
 static int set_pio_mode (ide_drive_t *drive, int arg)
diff -puN drivers/ide/ide-iops.c~ide_dma_off_fix drivers/ide/ide-iops.c
--- linux-2.6.3-rc3/drivers/ide/ide-iops.c~ide_dma_off_fix	2004-02-17 15:51:33.898340584 +0100
+++ linux-2.6.3-rc3-root/drivers/ide/ide-iops.c	2004-02-17 15:59:43.264945552 +0100
@@ -1125,16 +1125,17 @@ static ide_startstop_t reset_pollfunc (i
 	return ide_stopped;
 }
 
-void check_dma_crc (ide_drive_t *drive)
+static void check_dma_crc(ide_drive_t *drive)
 {
+#ifdef CONFIG_BLK_DEV_IDEDMA
 	if (drive->crc_count) {
 		(void) HWIF(drive)->ide_dma_off_quietly(drive);
 		ide_set_xfer_rate(drive, ide_auto_reduce_xfer(drive));
 		if (drive->current_speed >= XFER_SW_DMA_0)
 			(void) HWIF(drive)->ide_dma_on(drive);
-	} else {
+	} else
 		(void)__ide_dma_off(drive);
-	}
+#endif
 }
 
 void pre_reset (ide_drive_t *drive)
diff -puN drivers/ide/setup-pci.c~ide_dma_off_fix drivers/ide/setup-pci.c
--- linux-2.6.3-rc3/drivers/ide/setup-pci.c~ide_dma_off_fix	2004-02-17 16:08:16.775880024 +0100
+++ linux-2.6.3-rc3-root/drivers/ide/setup-pci.c	2004-02-17 16:09:58.969344256 +0100
@@ -150,6 +150,8 @@ static int ide_setup_pci_baseregs (struc
 	return 0;
 }
 
+#ifdef CONFIG_BLK_DEV_IDEDMA_PCI
+
 #ifdef CONFIG_BLK_DEV_IDEDMA_FORCED
 /*
  * Long lost data from 2.0.34 that is now in 2.0.39
@@ -279,6 +281,7 @@ second_chance_to_dma:
 	}
 	return dma_base;
 }
+#endif /* CONFIG_BLK_DEV_IDEDMA_PCI */
 
 void ide_setup_pci_noise (struct pci_dev *dev, ide_pci_device_t *d)
 {
diff -puN include/linux/ide.h~ide_dma_off_fix include/linux/ide.h
--- linux-2.6.3-rc3/include/linux/ide.h~ide_dma_off_fix	2004-02-17 16:19:28.044831632 +0100
+++ linux-2.6.3-rc3-root/include/linux/ide.h	2004-02-17 16:26:07.364125872 +0100
@@ -1626,6 +1626,9 @@ extern ide_startstop_t __ide_dma_queued_
 extern ide_startstop_t __ide_dma_queued_write(ide_drive_t *drive);
 extern ide_startstop_t __ide_dma_queued_start(ide_drive_t *drive);
 #endif
+
+#else
+static inline int __ide_dma_off(ide_drive_t *drive) { return 0; }
 #endif /* CONFIG_BLK_DEV_IDEDMA */
 
 #ifndef CONFIG_BLK_DEV_IDEDMA_PCI

_

Re: Linux 2.6.3-rc4 (compile stats)

[John Cherry]

Linux 2.6 Compile Statistics (gcc 3.2.2)
Warnings/Errors Summary

Kernel         bzImage    bzImage  bzImage  modules  bzImage   modules
             (defconfig)  (allno)  (allyes) (allyes) (allmod) (allmod)
-----------  -----------  -------- -------- -------- -------- ---------
2.6.3-rc4      1w/0e       0w/0e   142w/ 0e   9w/0e   3w/0e    142w/0e
2.6.3-rc3      1w/0e       0w/0e   145w/ 7e   9w/0e   3w/0e    148w/0e
2.6.3-rc2      1w/0e       0w/0e   141w/ 0e   9w/0e   3w/0e    144w/0e
2.6.3-rc1      1w/0e       0w/0e   145w/ 0e   9w/0e   3w/0e    177w/0e
2.6.2          1w/0e       0w/0e   152w/ 0e  12w/0e   3w/0e    187w/0e
2.6.2-rc3      0w/0e       0w/0e   152w/ 0e  12w/0e   3w/0e    187w/0e
2.6.2-rc2      0w/0e       0w/0e   153w/ 8e  12w/0e   3w/0e    188w/0e
2.6.2-rc1      0w/0e       0w/0e   152w/ 0e  12w/0e   3w/0e    187w/0e
2.6.1          0w/0e       0w/0e   158w/ 0e  12w/0e   3w/0e    197w/0e
2.6.1-rc3      0w/0e       0w/0e   158w/ 0e  12w/0e   3w/0e    197w/0e
2.6.1-rc2      0w/0e       0w/0e   166w/ 0e  12w/0e   3w/0e    205w/0e
2.6.1-rc1      0w/0e       0w/0e   167w/ 0e  12w/0e   3w/0e    206w/0e
2.6.0          0w/0e       0w/0e   170w/ 0e  12w/0e   3w/0e    209w/0e

Web page with links to complete details:
   http://developer.osdl.org/cherry/compile/
Daily compiles (ia32): 
   http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt
Daily compiles (ia64): 
   http://developer.osdl.org/cherry/compile/2.6/linus-tree/running64.txt
Latest changes in Linus' bitkeeper tree:
   http://linux.bkbits.net:8080/linux-2.5

John

Re: Linux 2.6.3-rc4

[GCS]

Hi Linus,

On Mon, Feb 16, 2004 at 07:51:08PM -0800, Linus Torvalds <torvalds@osdl.org> wrote:
>  I'm planning on doing the final 2.6.3 tomorrow, so please test this 
> final -rc.
> 
> Most notably, this should support ppc/ppc64 out-of-the-box, complete with
> G5 support (64-bit). Special thanks to BenH who made sure the new radeonfb
> driver works on a wide variety of hardware (a number of the fixes here
> relative to -rc3 was making sure the driver works on regular x86 laptops).
 For me on a laptop with integrated Radeon Mobility card:
  LD      .tmp_vmlinux1
drivers/built-in.o(.text+0xb2a03): In function `radeon_setup_i2c_bus':
: undefined reference to `i2c_bit_add_bus'
drivers/built-in.o(.text+0xb2b7a): In function `radeon_delete_i2c_busses':
: undefined reference to `i2c_bit_del_bus'
drivers/built-in.o(.text+0xb2b8a): In function `radeon_delete_i2c_busses':
: undefined reference to `i2c_bit_del_bus'
drivers/built-in.o(.text+0xb2b9a): In function `radeon_delete_i2c_busses':
: undefined reference to `i2c_bit_del_bus'
drivers/built-in.o(.text+0xb2baa): In function `radeon_delete_i2c_busses':
: undefined reference to `i2c_bit_del_bus'
drivers/built-in.o(.text+0xb2c44): In function `radeon_do_probe_i2c_edid':
: undefined reference to `i2c_transfer'
make: *** [.tmp_vmlinux1] Error 1

.config snippshet:
# CONFIG_FB_RADEON_OLD is not set
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_DEBUG=y
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set

Distribution: Debian Sid, gcc is gcc version 3.3.3 20040214 (prerelease)
(Debian)

AFAICR -rc3 was the first version with this problem.

Cheers,
GCS

Re: Linux 2.6.3-rc4

[Jonathan Brown]

Linus Torvalds wrote:
> Ok,
>  I'm planning on doing the final 2.6.3 tomorrow, so please test this 
> final -rc.
> 
> Most notably, this should support ppc/ppc64 out-of-the-box, complete with
> G5 support (64-bit). Special thanks to BenH who made sure the new radeonfb
> driver works on a wide variety of hardware (a number of the fixes here
> relative to -rc3 was making sure the driver works on regular x86 laptops).

There are still two problems with the radeonfb on my IBM X31:

1) The screen is garbled when the fb kicks in at boot - its not 
converting the text from the VGA console correctly. I have a photo of 
this here: http://emergence.uk.net/radeonfb_corruption.jpeg

2) If I run X and then exit X or switch to a fb vt then the bottom line 
doesn't clear when scrolling and running `clear` only clears the middle 
line of pixels on each line of text.

radeonfb_pci_register BEGIN
radeonfb: probed DDR SGRAM 16384k videoram
radeonfb: mapped 16384k videoram
radeonfb: Invalid ROM signature 0 should be 0xaa55
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=144.00 Mhz, 
System=144.00 MHz
1 chips in connector info
  - chip 1 has 1 connectors
   * connector 0 of type 2 (CRT) : 2300
Starting monitor auto detection...
Non-DDC laptop panel detected
radeonfb: Monitor 1 type LCD found
radeonfb: Monitor 2 type no found
radeonfb: panel ID string: 1024x768
radeonfb: detected LVDS panel size from BIOS: 1024x768
BIOS provided panel power delay: 1000
radeondb: BIOS provided dividers will be used
ref_divider = 8
post_divider = 2
fbk_divider = 4d
Scanning BIOS table ...
  320 x 350
  320 x 400
  320 x 400
  320 x 480
  400 x 600
  512 x 384
  640 x 350
  640 x 400
  640 x 475
  640 x 480
  720 x 480
  720 x 576
  800 x 600
  848 x 480
  1024 x 768
Found panel in BIOS table:
   hblank: 320
   hOver_plus: 16
   hSync_width: 136
   vblank: 38
   vOver_plus: 2
   vSync_width: 6
   clock: 6500
Setting up default mode based on panel info
radeonfb: Power Management enabled for Mobility chipsets
radeonfb: ATI Radeon LY  DDR SGRAM 16 MB
radeonfb_pci_register END


Jonathan Brown
http://emergence.uk.net/

Re: Linux 2.6.3-rc4

[Linus Torvalds]

On Tue, 17 Feb 2004, Jonathan Brown wrote:
> 
> There are still two problems with the radeonfb on my IBM X31:
> 
> 1) The screen is garbled when the fb kicks in at boot - its not 
> converting the text from the VGA console correctly. I have a photo of 
> this here: http://emergence.uk.net/radeonfb_corruption.jpeg

Yup, I see it too, it looks like it's just that fbcon doesn't clear the 
backing store when it does a resolution switch, so when the bootup process 
switches from the original VGA 80x25 text mode into 200x75 or whatever, it 
has random garbage in the new area.

It scrolls away, so it's a beauty wart at worst. I haven't bothered to 
look into where the missing clear is. Hint hint.

> 2) If I run X and then exit X or switch to a fb vt then the bottom line 
> doesn't clear when scrolling and running `clear` only clears the middle 
> line of pixels on each line of text.

This is due to the issue that I and BenH discussed on the kernel mailing 
list under the subject 

	2.6.3-rc3 radeonfb: Problems with new (and old) driver

where radeonfb doesn't even get the callback to reset the graphics engine,
so when X has changed some of the engine setup, radeonfb does the wrong 
thing afterwards. BenH already posted a patch, but I complained about how 
ugly it was ;)

So this will get fixed, but it almost certainly won't be fixed by 2.6.3.

		Linus

Re: Linux 2.6.3-rc4

[Linus Torvalds]

On Tue, 17 Feb 2004, GCS wrote:
>
> drivers/built-in.o(.text+0xb2c44): In function `radeon_do_probe_i2c_edid':
> : undefined reference to `i2c_transfer'
> make: *** [.tmp_vmlinux1] Error 1
> 
> .config snippshet:
> # CONFIG_FB_RADEON_OLD is not set
> CONFIG_FB_RADEON=y
> CONFIG_FB_RADEON_I2C=y
> CONFIG_FB_RADEON_DEBUG=y

I don't see this. What's your I2C config, and how did you generate your 
config file?

CONFIG_FB_RADEON_I2C should depend on CONFIG_I2C, and it selects 
I2C_ALGOBIT, but your error messages seem to imply that you don't have i2c 
enabled at all.

Which implies a configuration error (but the Kconfig file looks correct, 
so I wonder if you found a bug in the configurator).

		Linus

Re: Linux 2.6.3-rc4

[Adrian Bunk]

On Tue, Feb 17, 2004 at 11:09:45AM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 17 Feb 2004, GCS wrote:
> >
> > drivers/built-in.o(.text+0xb2c44): In function `radeon_do_probe_i2c_edid':
> > : undefined reference to `i2c_transfer'
> > make: *** [.tmp_vmlinux1] Error 1
> > 
> > .config snippshet:
> > # CONFIG_FB_RADEON_OLD is not set
> > CONFIG_FB_RADEON=y
> > CONFIG_FB_RADEON_I2C=y
> > CONFIG_FB_RADEON_DEBUG=y
> 
> I don't see this. What's your I2C config, and how did you generate your 
> config file?
> 
> CONFIG_FB_RADEON_I2C should depend on CONFIG_I2C, and it selects 
> I2C_ALGOBIT, but your error messages seem to imply that you don't have i2c 
> enabled at all.
> 
> Which implies a configuration error (but the Kconfig file looks correct, 
> so I wonder if you found a bug in the configurator).

Most likely the problem is CONFIG_I2C=m and the fact that FB_RADEON_I2C
is a bool.

I don't know whether there's a better way to express this, but something 
like the following is required:

--- linux-2.6.3-rc4/drivers/video/Kconfig.old	2004-02-17 21:00:24.000000000 +0100
+++ linux-2.6.3-rc4/drivers/video/Kconfig	2004-02-17 21:01:53.000000000 +0100
@@ -644,7 +644,7 @@
 
 config FB_RADEON_I2C
 	bool "DDC/I2C for ATI Radeon support"
-	depends on FB_RADEON && I2C
+	depends on (FB_RADEON=m && I2C) || (FB_RADEON=y && I2C=y)
 	select I2C_ALGOBIT
 	default y
 	help


> 		Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.3-rc4

[Linus Torvalds]

On Tue, 17 Feb 2004, Adrian Bunk wrote:
> 
> Most likely the problem is CONFIG_I2C=m and the fact that FB_RADEON_I2C
> is a bool.
> 
> I don't know whether there's a better way to express this, but something 
> like the following is required:

Argh. Yeah, that's ugly.

How about instead just removing the dependency on I2C, and making it just
select it? (in fact, I'd assume that just selecing I2C_ALGOBIT should
itself cause I2C to be selected, but I've not checked the dependency
chain).

That's really what the true dependency is, logically.

		Linus

Re: Linux 2.6.3-rc4

[Adrian Bunk]

On Tue, Feb 17, 2004 at 12:16:08PM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 17 Feb 2004, Adrian Bunk wrote:
> > 
> > Most likely the problem is CONFIG_I2C=m and the fact that FB_RADEON_I2C
> > is a bool.
> > 
> > I don't know whether there's a better way to express this, but something 
> > like the following is required:
> 
> Argh. Yeah, that's ugly.
> 
> How about instead just removing the dependency on I2C, and making it just
> select it? (in fact, I'd assume that just selecing I2C_ALGOBIT should
> itself cause I2C to be selected, but I've not checked the dependency
> chain).

No, I2C_ALGOBIT depends on I2C.

> That's really what the true dependency is, logically.

Below is a suggested fix that lets FB_RADEON_I2C select I2C.

It also fixes FB_MATROX_I2C that has a similar problem.

> 		Linus

cu
Adrian

--- linux-2.6.3-rc4/drivers/video/Kconfig.old	2004-02-17 21:00:24.000000000 +0100
+++ linux-2.6.3-rc4/drivers/video/Kconfig	2004-02-17 23:54:56.000000000 +0100
@@ -505,10 +505,8 @@
 	  pixel and 32 bpp packed pixel. You can also use font widths
 	  different from 8.
 
-	  If you need support for G400 secondary head, you must first say Y to
-	  "I2C support" and "I2C bit-banging support" in the character devices
-	  section, and then to "Matrox I2C support" and "G400 second head
-	  support" here in the framebuffer section. G450/G550 secondary head
+	  If you need support for G400 secondary head, you must say Y to
+	  "G400 second head support" below. G450/G550 secondary head
 	  and digital output are supported without additional modules.
 
 	  The driver starts in monitor mode. You must use the matroxset tool 
@@ -537,9 +535,7 @@
 	  different from 8.
 
 	  If you need support for G400 secondary head, you must first say Y to
-	  "I2C support" and "I2C bit-banging support" in the character devices
-	  section, and then to "Matrox I2C support" and "G400 second head
-	  support" here in the framebuffer section.
+	  "G400 second head support" below.
 
 config FB_MATROX_G100
 	bool
@@ -548,7 +544,8 @@
 
 config FB_MATROX_I2C
 	tristate "Matrox I2C support"
-	depends on FB_MATROX && I2C
+	depends on FB_MATROX
+	select I2C
 	select I2C_ALGOBIT
 	---help---
 	  This drivers creates I2C buses which are needed for accessing the
@@ -632,19 +629,13 @@
 	  a framebuffer device.  There are both PCI and AGP versions.  You
 	  don't need to choose this to run the Radeon in plain VGA mode.
 
-	  If you say Y here and want DDC/I2C support you must first say Y to
-	  "I2C support" and "I2C bit-banging support" in the character devices
-	  section.
-
-	  If you say M here then "I2C support" and "I2C bit-banging support" 
-	  can be build either as modules or built-in.
-
 	  There is a product page at
 	  <http://www.ati.com/na/pages/products/pc/radeon32/index.html>.
 
 config FB_RADEON_I2C
 	bool "DDC/I2C for ATI Radeon support"
-	depends on FB_RADEON && I2C
+	depends on FB_RADEON
+	select I2C
 	select I2C_ALGOBIT
 	default y
 	help

Re: Linux 2.6.3-rc4

[Linus Torvalds]

On Tue, 17 Feb 2004, Adrian Bunk wrote:
> 
> No, I2C_ALGOBIT depends on I2C.
> 
> > That's really what the true dependency is, logically.
> 
> Below is a suggested fix that lets FB_RADEON_I2C select I2C.

Thinking about it, this does the wrong thing for _another_ reason.

Basically, if you compile radeonfb as a module, and say "Y" to RADEON_I2C, 
then that should _not_ force I2C to be built-in to the kernel, but that 
is in fact exactly what this would force.

Damn. I think your first patch was "more correct", but there's no question
that it was also pretty ugly and had exactly the same problem wrt
I2C_ALGOBIT, methinks.

What we actually want to say is something like "select I2C=FB_RADEON",
which makes the minimal dependency of I2C be the same value as FB_RADEON
(which is a tristate) rather than FB_RADEON_I2C (boolean).

Roman, maybe you can help with something that actually gets this right? 

			Linus

Radeon issue on x86

[Benjamin Herrenschmidt]

Hi Linus !

One of the issue I'm having with raeonfb on x86 is the need
to retreive the panel informations out of the BIOS. My current
algorithm is to try to retreive that from the PCI ROM of the
video chip, and if I cannot find any, then look at the BIOS ROM
image in low memory.

However, I got a few reports of that not working. Usually, on
laptops, apparently, the PCI ROM doesn't exist and it can all
be found in the low memory image (I suppose the video BIOS on
these is hidden somewhere with the main BIOS and copied to RAM
at aboot). BUT, some laptops like some Dell inspirons will show
a valid PCI ROM (valid signature) on the video chip, though
this ROM appear to not contain any useable panel information
table :( However, on these, the RAM image do seem to contain
the table... So I would need to reverse my algorithm and
default to the RAM BIOS on laptops at least...

The problem with the RAM image is that it's only there for the
primary display chip that was initialized at boot. So I would
need to "know" which PCI card is the primary display. That's all
x86 architecture black magic, so I'd like your advice on the best
way to do that. Also, that low memory region at c0000, what is
it's exact format ? I currently copied a search routine from
XFree but it does very little verifications in there, I'm a bit
paranoid about picking the wrong thing...

What do you suggest ?

Ben.

Re: Linux 2.6.3-rc4

[Adrian Bunk]

On Tue, Feb 17, 2004 at 03:11:08PM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 17 Feb 2004, Adrian Bunk wrote:
> > 
> > No, I2C_ALGOBIT depends on I2C.
> > 
> > > That's really what the true dependency is, logically.
> > 
> > Below is a suggested fix that lets FB_RADEON_I2C select I2C.
> 
> Thinking about it, this does the wrong thing for _another_ reason.
> 
> Basically, if you compile radeonfb as a module, and say "Y" to RADEON_I2C, 
> then that should _not_ force I2C to be built-in to the kernel, but that 
> is in fact exactly what this would force.
>...

I don't claim to fully understand the 2.6 Kconfig language, but 
according to my testings my patch does exactly what you describe.

> 			Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.3-rc4

[Roman Zippel]

Hi,

On Tue, 17 Feb 2004, Adrian Bunk wrote:

> > Which implies a configuration error (but the Kconfig file looks correct,
> > so I wonder if you found a bug in the configurator).
>
> Most likely the problem is CONFIG_I2C=m and the fact that FB_RADEON_I2C
> is a bool.

Try the patch below. I noticed that problem recently and I hoped I could
get away with it after 2.6.3. :)
When calculating the select expression it should only use the config
symbol itself not the complete dependency, otherwise a boolean could be
turned into a tristate.

bye, Roman

--- linux/scripts/kconfig/menu.c	18 Jul 2003 21:22:54 -0000	1.1.1.1
+++ linux/scripts/kconfig/menu.c	17 Feb 2004 20:18:28 -0000
@@ -172,16 +172,16 @@ void menu_finalize(struct menu *parent)
 				if (prop->menu != menu)
 					continue;
 				dep = expr_transform(prop->visible.expr);
-				dep = expr_alloc_and(expr_copy(basedep), dep);
-				dep = expr_eliminate_dups(dep);
-				if (menu->sym && menu->sym->type != S_TRISTATE)
-					dep = expr_trans_bool(dep);
-				prop->visible.expr = dep;
 				if (prop->type == P_SELECT) {
 					struct symbol *es = prop_get_symbol(prop);
 					es->rev_dep.expr = expr_alloc_or(es->rev_dep.expr,
 							expr_alloc_and(expr_alloc_symbol(menu->sym), expr_copy(dep)));
 				}
+				dep = expr_alloc_and(expr_copy(basedep), dep);
+				dep = expr_eliminate_dups(dep);
+				if (menu->sym && menu->sym->type != S_TRISTATE)
+					dep = expr_trans_bool(dep);
+				prop->visible.expr = dep;
 			}
 		}
 		for (menu = parent->list; menu; menu = menu->next)

Re: Radeon issue on x86

[Linus Torvalds]

On Wed, 18 Feb 2004, Benjamin Herrenschmidt wrote:
> 
> However, I got a few reports of that not working. Usually, on
> laptops, apparently, the PCI ROM doesn't exist and it can all
> be found in the low memory image (I suppose the video BIOS on
> these is hidden somewhere with the main BIOS and copied to RAM
> at aboot).

More commonly, the system BIOS is compressed. On laptops in particular, 
chip count actually matters, so there is often only _one_ flash ROM, and 
it contains both the regular system rom and the video ROM, and almost 
always in compressed format. It's then uncompressed into RAM, and the RAM 
is marked non-writable in the chipset.

>	 So I would need to reverse my algorithm and
> default to the RAM BIOS on laptops at least...

It's almost certainly worth doing it even on desktops too, since the above
is quite likely to be true at least for integrated chipsets (for cost 
reasons, if not for size reasons).

> The problem with the RAM image is that it's only there for the
> primary display chip that was initialized at boot. So I would
> need to "know" which PCI card is the primary display.

I can't help you on that one. You'd have to figure the "which chip is the 
primary" out on yourself, although you are likely to be able to figure it 
out by just following the trace of who has the legacy area mapped (ie who 
has the 0xA0000 - 0xCFFFF IO region enabled).

On PCI bridges, that _should_ be visible by checking which bridge has
"VGASnoop" on (and if none, default to the VGA device closest to the
root). But I don't know - I've never tried to do this myself. I assume 
XFree86 must have some strange code to do this.

>							 That's all
> x86 architecture black magic, so I'd like your advice on the best
> way to do that. Also, that low memory region at c0000, what is
> it's exact format ?

There is no exact format. It's allowed to look pretty much any way it
wants, although you're _supposed_ to have the marker 0x55, 0xAA in the
first two bytes. That's how the system BIOS historically figures out that 
there is an extension ROM there somewhere.

The rule is, I think, that the primary video ROM should be at address
0xC0000. There might be alternate ROM start points at 2kB boundaries (in
the whole 0xC0000 .. 0xFFFFF range).

Oh, and byte 2 should have the "length indicator", which is the size of 
the ROM in 512-byte blocks, while "byte 3" is actually the first 
instruction to be run at initialization. So if you want to verify more, 
you should be able to disassemble "start+3" into a valid instruction, and 
"start+2" should have a sensible value, but especially that "rom length" I 
don't know how accurate it is.

The reason I say "should be" is that I would not be totally surprised if a 
video ROM that is embedded with the system ROM might not skip that part, 
since the system ROM "knows" that it is there regardless of signature. 

I just checked my EVO rom, and I notice that it _does_ have the signature
0xAA55 at 0xC0000, and the byte 0x80 at byte offset 2 (implying 65536
bytes, which should be correct). So that's likely to be the right thing to
check.

> I currently copied a search routine from XFree but it does very little
> verifications in there, I'm a bit paranoid about picking the wrong
> thing...
> 
> What do you suggest ?

Does the above match what XFree86 does?

		Linus

Re: Linux 2.6.3-rc4

[GCS]

On Tue, Feb 17, 2004 at 11:09:45AM -0800, Linus Torvalds <torvalds@osdl.org> wrote:
> > drivers/built-in.o(.text+0xb2c44): In function `radeon_do_probe_i2c_edid':
> > : undefined reference to `i2c_transfer'
> > make: *** [.tmp_vmlinux1] Error 1
> > 
> > .config snippshet:
> > # CONFIG_FB_RADEON_OLD is not set
> > CONFIG_FB_RADEON=y
> > CONFIG_FB_RADEON_I2C=y
> > CONFIG_FB_RADEON_DEBUG=y
> 
> I don't see this. What's your I2C config, and how did you generate your 
> config file?
 I do not attach it, as I think I have found the root of the problem.
Usually I save my .config to a safe place, copy it into the kernel
source, do 'make oldconfig', and only if necessary I do 'make menuconfig'
as well.

> CONFIG_FB_RADEON_I2C should depend on CONFIG_I2C, and it selects 
> I2C_ALGOBIT, but your error messages seem to imply that you don't have i2c 
> enabled at all.
 I have. My shot would be that as CONFIG_FB_RADEON_I2C is y-n, but
CONFIG_I2C and CONFIG_I2C_ALGOBIT are tri-state as m in my case, the
problem can be that the functions are compiled into the module and
CONFIG_FB_RADEON_I2C can't find them in the static part of the kernel.
At least I do confirm that changing CONFIG_I2C and CONFIG_I2C_ALGOBIT
from m to y makes the problem disappear.

> Which implies a configuration error (but the Kconfig file looks correct, 
> so I wonder if you found a bug in the configurator).
 Can the configurator force the dependencies to the same state? For my
case it should have change my m's to y's.

Cheers,
GCS

Re: Radeon issue on x86

[Benjamin Herrenschmidt]

> I can't help you on that one. You'd have to figure the "which chip is the 
> primary" out on yourself, although you are likely to be able to figure it 
> out by just following the trace of who has the legacy area mapped (ie who 
> has the 0xA0000 - 0xCFFFF IO region enabled).
> 
> On PCI bridges, that _should_ be visible by checking which bridge has
> "VGASnoop" on (and if none, default to the VGA device closest to the
> root). But I don't know - I've never tried to do this myself. I assume 
> XFree86 must have some strange code to do this.

Hrm... I'm not sure how all of this works. Somebody suggested just
picking the VGA card that has IO enabled at boot (so basically
adding a quirk to x86 that "remembers" the pci_dev of whatever
VGA card had IO enabled during first PCI probe).
 
> There is no exact format. It's allowed to look pretty much any way it
> wants, although you're _supposed_ to have the marker 0x55, 0xAA in the
> first two bytes. That's how the system BIOS historically figures out that 
> there is an extension ROM there somewhere.

Ok.

> The rule is, I think, that the primary video ROM should be at address
> 0xC0000. There might be alternate ROM start points at 2kB boundaries (in
> the whole 0xC0000 .. 0xFFFFF range).
> 
> Oh, and byte 2 should have the "length indicator", which is the size of 
> the ROM in 512-byte blocks, while "byte 3" is actually the first 
> instruction to be run at initialization. So if you want to verify more, 
> you should be able to disassemble "start+3" into a valid instruction, and 
> "start+2" should have a sensible value, but especially that "rom length" I 
> don't know how accurate it is.

I think I'll keep my current loop... so far it worked fine... (just
check for the signature). I may be able to check ATI specific signatures
in there, I don't know if it's worth the pain...

> The reason I say "should be" is that I would not be totally surprised if a 
> video ROM that is embedded with the system ROM might not skip that part, 
> since the system ROM "knows" that it is there regardless of signature. 
> 
> I just checked my EVO rom, and I notice that it _does_ have the signature
> 0xAA55 at 0xC0000, and the byte 0x80 at byte offset 2 (implying 65536
> bytes, which should be correct). So that's likely to be the right thing to
> check.

Maybe I should actually do more sanity checking on the values I read
from the BIOS, and based on that, try everything again the "other"
way... Hrm... it's all pretty nasty, I don't even have an x86 box
with a radeon to play with yet ;)

> > I currently copied a search routine from XFree but it does very little
> > verifications in there, I'm a bit paranoid about picking the wrong
> > thing...
> > 
> > What do you suggest ?
> 
> Does the above match what XFree86 does?

It just does a loop looking for the aa55 signature.

Ben.

Re: Linux 2.6.3-rc4

[Roman Zippel]

Hi,

On Tue, 17 Feb 2004, Linus Torvalds wrote:

> What we actually want to say is something like "select I2C=FB_RADEON",
> which makes the minimal dependency of I2C be the same value as FB_RADEON
> (which is a tristate) rather than FB_RADEON_I2C (boolean).

You can do something similiar:

config FB_RADEON
	select I2C_ALGOBIT if FB_RADEON_I2C

but then you need the patch below to avoid a bogus warning about recursive
dependecies.
Note that the select mechanism is very simple, it's applied to the
selected symbol very late, so it can override any previous selection, but
this also means it ignores any dependencies of the selected symbol. I have
plans to modify the select mechanism for 2.7, but this will be more
complex, so I added something rather simple instead (it was already quite
late during 2.5).

bye, Roman

--- l/scripts/kconfig/symbol.c	8 Sep 2003 21:18:48 -0000	1.1.1.2
+++ l/scripts/kconfig/symbol.c	18 Feb 2004 00:31:00 -0000
@@ -706,7 +706,7 @@ struct symbol *sym_check_deps(struct sym
 		goto out;

 	for (prop = sym->prop; prop; prop = prop->next) {
-		if (prop->type == P_CHOICE)
+		if (prop->type == P_CHOICE || prop->type == P_SELECT)
 			continue;
 		sym2 = sym_check_expr_deps(prop->visible.expr);
 		if (sym2)

Re: Linux 2.6.3-rc4

[Roman Zippel]

Hi,

On Tue, 17 Feb 2004, Linus Torvalds wrote:

> What we actually want to say is something like "select I2C=FB_RADEON",
> which makes the minimal dependency of I2C be the same value as FB_RADEON
> (which is a tristate) rather than FB_RADEON_I2C (boolean).

Actually the same can be done this way either:

config FB_RADEON_I2C
	depends on FB_RADEON && I2C
	select I2C_ALGOBIT if FB_RADEON

to select only I2C_ALGOBIT or:

config FB_RADEON_I2C
	depends on FB_RADEON
	select I2C if FB_RADEON
	select I2C_ALGOBIT if FB_RADEON

to select both.
This adds the expression "FB_RADEON_I2C && FB_RADEON" to the selected
symbol as minimum selection.

bye, Roman

Re: Linux 2.6.3-rc4

[Roman Zippel]

Hi,

On Wed, 18 Feb 2004, Adrian Bunk wrote:

> > Basically, if you compile radeonfb as a module, and say "Y" to RADEON_I2C,
> > then that should _not_ force I2C to be built-in to the kernel, but that
> > is in fact exactly what this would force.
> >...
>
> I don't claim to fully understand the 2.6 Kconfig language, but
> according to my testings my patch does exactly what you describe.

It does that more by accident. I actually consider it an error that the
dependency of boolean symbol modifies how it does the selection (note that
the dependencies can be more than is immediately visible, e.g. from an
'if' or a 'menu' block), so I prefer if one want to limit the selection of
a boolean symbol to make this explicit (via an 'if' condition after the
selection).

bye, Roman

Re: Linux 2.6.3-rc4

[Roman Zippel]

Hi,

On Tue, 17 Feb 2004, Adrian Bunk wrote:

> @@ -548,7 +544,8 @@
>
>  config FB_MATROX_I2C
>  	tristate "Matrox I2C support"
> -	depends on FB_MATROX && I2C
> +	depends on FB_MATROX
> +	select I2C
>  	select I2C_ALGOBIT
>  	---help---
>  	  This drivers creates I2C buses which are needed for accessing the

This was okay, this is a tristate and limited by I2C, so it will select
I2C_ALGOBIT correctly.

>  config FB_RADEON_I2C
>  	bool "DDC/I2C for ATI Radeon support"
> -	depends on FB_RADEON && I2C
> +	depends on FB_RADEON
> +	select I2C
>  	select I2C_ALGOBIT
>  	default y
>  	help

Linus, I think that's the best solution for now. I have to think a bit
more about the problem, how a boolean symbol should select a tristate
symbol.

bye, Roman

Re: Linux 2.6.3-rc4

[Linus Torvalds]

On Wed, 18 Feb 2004, Roman Zippel wrote:
> 
> Linus, I think that's the best solution for now. I have to think a bit
> more about the problem, how a boolean symbol should select a tristate
> symbol.

Hmm.. I already rewrote it the way you suggested earlier, ie like the 
appended. A quick (but ny no means exhaustive) test implied that 
this works fine too.

		Linus

----
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1646  -> 1.1647 
#	drivers/video/Kconfig	1.38    -> 1.39   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 04/02/17	torvalds@home.osdl.org	1.1647
# Fix the dependency chain for I2C_ALGOBIT from the FB
# drivers that need it. 
# 
# This allows us to have I2C as a module iff the FB driver
# that needs it is a module.
# --------------------------------------------
#
diff -Nru a/drivers/video/Kconfig b/drivers/video/Kconfig
--- a/drivers/video/Kconfig	Tue Feb 17 18:57:36 2004
+++ b/drivers/video/Kconfig	Tue Feb 17 18:57:36 2004
@@ -462,6 +462,7 @@
 config FB_MATROX
 	tristate "Matrox acceleration"
 	depends on FB && PCI
+	select I2C_ALGOBIT if FB_MATROX_I2C
 	---help---
 	  Say Y here if you have a Matrox Millennium, Matrox Millennium II,
 	  Matrox Mystique, Matrox Mystique 220, Matrox Productiva G100, Matrox
@@ -549,7 +550,6 @@
 config FB_MATROX_I2C
 	tristate "Matrox I2C support"
 	depends on FB_MATROX && I2C
-	select I2C_ALGOBIT
 	---help---
 	  This drivers creates I2C buses which are needed for accessing the
 	  DDC (I2C) bus present on all Matroxes, an I2C bus which
@@ -627,6 +627,7 @@
 config FB_RADEON
 	tristate "ATI Radeon display support"
 	depends on FB && PCI
+	select I2C_ALGOBIT if FB_RADEON_I2C
 	help
 	  Choose this option if you want to use an ATI Radeon graphics card as
 	  a framebuffer device.  There are both PCI and AGP versions.  You
@@ -645,7 +646,6 @@
 config FB_RADEON_I2C
 	bool "DDC/I2C for ATI Radeon support"
 	depends on FB_RADEON && I2C
-	select I2C_ALGOBIT
 	default y
 	help
 	  Say Y here if you want DDC/I2C support for your Radeon board. 

Re: Linux 2.6.3-rc4

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3427 bytes --]

On Mon, 16 Feb 2004 19:51:08 -0800 (PST) Linus Torvalds <torvalds@osdl.org> wrote:
>
> Most notably, this should support ppc/ppc64 out-of-the-box

The following patch makes this even more true :-).  This patch lets
2.6.3-rc4 build and boot on an PPC64 iSeries box (at least for my
configuration).  The veth.o bit in the networking Makefile got there by
accident and should be removed anyway ...

There is more to make it work properly (note the "Temporary hack"), but
this gets us closer.

Please consider applying.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff -ruN 2.6.3-rc4/arch/ppc64/kernel/iSeries_irq.c 2.6.3-rc4-1/arch/ppc64/kernel/iSeries_irq.c
--- 2.6.3-rc4/arch/ppc64/kernel/iSeries_irq.c	2004-02-04 17:24:34.000000000 +1100
+++ 2.6.3-rc4-1/arch/ppc64/kernel/iSeries_irq.c	2004-02-18 14:50:04.000000000 +1100
@@ -57,6 +57,7 @@
 
 void iSeries_init_irq_desc(irq_desc_t *desc)
 {
+	desc->handler = &iSeries_IRQ_handler;
 }
 
 /* This is called by init_IRQ.  set in ppc_md.init_IRQ by iSeries_setup.c */
@@ -87,22 +88,6 @@
 #define IRQ_TO_IDSEL(irq)	(((((irq) - 1) >> 3) & 7) + 1)
 #define IRQ_TO_FUNC(irq)	(((irq) - 1) & 7)
 
-/*
- * This is called out of iSeries_scan_slot to assign the EADS slot
- * to its IRQ number
- */
-int __init iSeries_assign_IRQ(int irq, HvBusNumber busNumber,
-		HvSubBusNumber subBusNumber, HvAgentId deviceId)
-{
-	irq_desc_t *desc = get_real_irq_desc(irq);
-
-	if (desc == NULL)
-		return -1;
-	desc->handler = &iSeries_IRQ_handler;
-	return 0;
-}
-
-
 /* This is called by iSeries_activate_IRQs */
 static unsigned int iSeries_startup_IRQ(unsigned int irq)
 {
@@ -125,6 +110,11 @@
 }
 
 /*
+ * Temporary hack
+ */
+#define get_irq_desc(irq)	&irq_desc[(irq)]
+
+/*
  * This is called out of iSeries_fixup to activate interrupt
  * generation for usable slots
  */
diff -ruN 2.6.3-rc4/arch/ppc64/kernel/iSeries_pci.c 2.6.3-rc4-1/arch/ppc64/kernel/iSeries_pci.c
--- 2.6.3-rc4/arch/ppc64/kernel/iSeries_pci.c	2004-02-18 11:30:38.000000000 +1100
+++ 2.6.3-rc4-1/arch/ppc64/kernel/iSeries_pci.c	2004-02-18 14:43:09.000000000 +1100
@@ -406,7 +406,6 @@
 
 	/* iSeries_allocate_IRQ.: 0x18.00.12(0xA3) */
   	Irq = iSeries_allocate_IRQ(Bus, 0, EADsIdSel);
-	iSeries_assign_IRQ(Irq, Bus, 0, EADsIdSel);
 	PPCDBG(PPCDBG_BUSWALK,
 		"PCI:- allocate and assign IRQ 0x%02X.%02X.%02X = 0x%02X\n",
 		Bus, 0, EADsIdSel, Irq);
diff -ruN 2.6.3-rc4/arch/ppc64/kernel/iSeries_setup.c 2.6.3-rc4-1/arch/ppc64/kernel/iSeries_setup.c
--- 2.6.3-rc4/arch/ppc64/kernel/iSeries_setup.c	2004-02-18 11:30:38.000000000 +1100
+++ 2.6.3-rc4-1/arch/ppc64/kernel/iSeries_setup.c	2004-02-18 14:37:32.000000000 +1100
@@ -315,7 +315,6 @@
 	ppc_md.setup_residual = iSeries_setup_residual;
 	ppc_md.get_cpuinfo = iSeries_get_cpuinfo;
 	ppc_md.init_IRQ = iSeries_init_IRQ;
-	ppc_md.init_irq_desc = iSeries_init_irq_desc;
 	ppc_md.get_irq = iSeries_get_irq;
 	ppc_md.init = NULL;
 
diff -ruN 2.6.3-rc4/drivers/net/Makefile 2.6.3-rc4-1/drivers/net/Makefile
--- 2.6.3-rc4/drivers/net/Makefile	2004-02-18 11:30:51.000000000 +1100
+++ 2.6.3-rc4-1/drivers/net/Makefile	2004-02-18 14:40:06.000000000 +1100
@@ -45,7 +45,6 @@
 obj-$(CONFIG_SIS900) += sis900.o
 obj-$(CONFIG_YELLOWFIN) += yellowfin.o
 obj-$(CONFIG_ACENIC) += acenic.o
-obj-$(CONFIG_VETH) += veth.o
 obj-$(CONFIG_NATSEMI) += natsemi.o
 obj-$(CONFIG_NS83820) += ns83820.o
 obj-$(CONFIG_STNIC) += stnic.o 8390.o

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux 2.6.3-rc4

[Andreas Happe]

On 2004-02-17, Jonathan Brown <jbrown@emergence.uk.net> wrote:
> There are still two problems with the radeonfb on my IBM X31:
>
> 1) The screen is garbled when the fb kicks in at boot - its not 
> converting the text from the VGA console correctly. I have a photo of 
> this here: http://emergence.uk.net/radeonfb_corruption.jpeg

got the same problem with the old radeonfb since the 2.5 series.

	--Andreas