Hey, I hoped -rc4 was the last one, but we had some laptop resource
conflicts, various ppc TLB flush issues, some possible stack overflows in
networking and a number of other details warranting a quick -rc5 before
the final 2.6.11.
This time it's really supposed to be a quickie, so people who can, please
check it out, and we'll make the real 2.6.11 asap.
Mostly pretty small changes (the largest is a new SATA driver that crept
in, our bad). But worth another quick round.
Linus
----
Summary of changes from v2.6.11-rc4 to v2.6.11-rc5
============================================
<benh:au1.ibm.com>:
o ppc32: Wrong vaddr in flush_hash_one_pte()
<mat.loikkanen:synopsys.com>:
o [libata] add ->bmdma_{stop,status} hooks
Alan Stern:
o USB Hub driver: Add reset recovery-time delay
Andrew Morton:
o mca resource layout fix
o end_buffer_async_read printk ratelimiting
o strip.c build fix
o alpha: struct resource fix
o ppc32: resource layout fixes
o sparc64 rusage build fix
o sparc64 usb build fix
o x86_64: resource layout fix
Anton Blanchard:
o ppc64: Fix 32bit largepage issue
Antonino Daplas:
o fbdev: Fix gcc 4.0 compile failure
Arjan van de Ven:
o Allow heap to be marked executable too
Arnaldo Carvalho de Melo:
o [TCP]: Fix excessive stack usage resulting in OOPS with 4KSTACKS
Art Haas:
o [SPARC]:Check prom_getproperty() return value in prom_nodematch()
Bartlomiej Zolnierkiewicz:
o [ide] fix ide_get_error_location() for LBA28
Ben Dooks:
o [ARM PATCH] 2480/1: IXP4XX - cleanup resource for i2c controller
o [ARM PATCH] 2481/1: IXP2000 - replace sti/cli with
local_irq{save,restore}
o [ide] Kconfig for VR1000 machine driver selection
Benjamin Herrenschmidt:
o radeonfb: typos fixes
o radeonfb: Fix hang on boot with some laptops
o Fix possible race with 4level-fixup.h
o Check for wraps in copy_page_range
o Fix buf in zeromap_pud_range() losing virtual address
o radeonfb: Workaround memory corruption accel problem
o ppc32: fix ptep_test_and_clear_young
o ppc32: kernel mapping breakage
Bjorn Helgaas:
o de214x.c uses uninitialized pci_dev->irq
Bob Breuer:
o [SPARC]: Check prom_getproperty return value
Brian Murphy:
o USB: ehci requeue revisit
Christoph Hellwig:
o block new writers on frozen filesystems
Corey Minyard:
o IPMI: Fix LAN bridging
Daniel Ritz:
o PCI: support PCI_PM_CAP version 1
David Brownell:
o USB: ehci patch for NF4 port miscounting
David S. Miller:
o [COMPAT]: TUNSETIFF needs to copy back data after ioctl
o [SPARC]: Fix cg3 fb blanking
o [SPARC]: Fix video mode probing in atyfb driver
o [TG3]: Always check tg3_readphy() return value
o [TG3]: Update driver version and reldate
o [SPARC64]: auxio_register is pointer not integer
o [SPARC64]: Put PROM trampolines into asm file
o [SPARC64]: Fix access_ok() and friends warnings
o [SPARC64]: Fix access_ok() args in sys_sparc32.c:get_tv32()
o [SPARC64]: Use common sys_ipc() compat code
o [SPARC64]: BUG on rediculious memcpy lengths
Dmitry Torokhov:
o ALPS: do not activate on unsupported models
Fran?ois Romieu:
o dscc4: use of uncompletely initialized struct
o dscc4: code factorisation
o dscc4: error status checking and pci janitoring
o dscc4: removal of unneeded casts
o dscc4: removal of unneeded variable
o r8169: endianness fixes
o r8169: merge of Realtek's code
o r8169: typo in debugging code
o r8169: screaming irq when the device is closed
o r8169: synchronization and balancing when the device is closed
o r8169: fix rx skb allocation error logging
o r8169: skb alignment nitpicking
o r8169: removal of unused #define
o r8169: uniformize comments
o r8169: IRQ races during change of mtu
o r8169: factor out some code
Gary N. Spiess:
o natsemi long cable fix
Herbert Xu:
o ISDN locking fix
o [IPSEC]: Move dst->child loop from dst_ifdown to xfrm_dst_ifdown
o [NET]: Add netdev argument to dst ifdown
Hideaki Yoshifuji:
o [IPV6]: Fix IPV6_PKTINFO et al. handling in udpv6_recvmsg()
Hirokazu Takata:
o m32r: build fix for SMP kernel
o m32r: fix sys_clone()
o m32r: defconfig updates
o m32r: warning fix
Jeff Garzik:
o [libata sata_via] minor cleanups
o [libata sata_via] add support for VT6421 SATA
o [libata] do not call pci_disable_device() for certain errors
o libata kfree fix
o [libata] Add missing hooks, to avoid oops in advanced SATA drivers
Joe Korty:
o memset argument order misuses
John W. Linville:
o libata: fix command queue leak when xlat_func fails
Krzysztof Helt:
o [SPARC32]: Need to clear PSR_EF in psr of childregs on fork() on
SMP
Len Brown:
o [ACPI] ACPICA 20050211 from Bob Moore
Lennert Buytenhek:
o [ARM PATCH] 2485/1: fix enp2611 coexistence with other machine
types
o [ARM PATCH] 2486/1: fix incorrect comment in
arch/arm/kernel/debug.S
o [ARM PATCH] 2487/1: minor IRQ routing tweaks for ENP-2611
o [ARM PATCH] 2493/1: put IXP2000 slowport in 8-bit mode after boot
o [ARM PATCH] 2494/1: fix 'CONFGI_' -> 'CONFIG_' in
mach-ixp2000/ixdp2x00.c
Linus Torvalds:
o Eicon driver: remove ^M for real this time
o Limit tty IO chunking to 2kB
o Fix bogus opost buffer size check
o Input: fix ALPS protocol validation rules
o Use e820 memory map to determine PCI allocation area
o Be more careful about looking for gaps in the e820 table
o x86: when choosing PCI starting address, print out gap information
o agp: aper_base is unsigned
o Linux 2.6.11-rc5
Marcel Holtmann:
o [Bluetooth] The new Microsoft dongle needs HCI_Reset
Mark Lord:
o sata_qstor: new basic driver for Pacific Digital
Matt Porter:
o emac: fix jumbo frame support
o emac: fix mdio delay
Mika Kukkonen:
o [ide] small compile fix to ide.c with !CONFIG_PCI
o Build failure with !CONFIG_PCI and with CONFIG_ISAPNP=y &&
CONFIG_PNPBIOS=y
Nathan Scott:
o [XFS] Reinstate missing frozen check on write, fixes snapshots and
xfs_freeze.
o [XFS] Prevent releasepage from releasing pages early, while they
still have delayed allocate buffers. Affects filesystem blocksizes
smaller than the pagesize only.
o [XFS] Fix problems with synchronous writes returning EAGAIN
incorrectly for pinned inodes.
Nathan T. Lynch:
o kthread_bind new worker threads when onlining cpu
Nick Piggin:
o optimise copy page range
Olaf Hering:
o ppc64: remove extra whitespace before preprocessor token
o [NET]: Fix socket.h comment typo
Olof Johansson:
o Fix possible futex mmap_sem deadlock
Paul Mackerras:
o ppc64: fix compilation for Maple board
Pete Zaitcev:
o USB: Add ioctls to ub
o ub: fix Add ioctls to ub patch
Ralf B?chle:
o [NETROM/ROSE]: Use netdev_priv()
Randy Dunlap:
o sis: fix sparse warnings
o au1100: fix io_remap_page_range() arg. list
Ravinandan Arakali:
o S2io: Multicast fix
Robert Olsson:
o [PKTGEN]: Bug fixes, bump to version 2.56
Rolf Eike Beer:
o make ACPI_BLACKLIST_YEAR depend on ACPI_INTERPRETER
Russell King:
o [ARM] Add missing __user annotations to sys_clone()
o [ARM] Fix SA1111 and PXA iomem sparse warnings
o [ARM] Fix sparse warnings for Integrator builds
o [ARM] Take account of vm_pgoff for DMA mmap
Stephen Hemminger:
o [TCP]: Fix BIC max_cwnd calculation error
Thomas Gleixner:
o [ARM PATCH] 2474/1: Fix compile for badge4
o [ARM PATCH] 2476/1: Fix compile for shannon
o [ARM PATCH] 2478/1: Remove NULL initializers
Tim Burgess:
o device-mapper: dm-raid1 deadlock fix
Tom Rini:
o ppc32: fixup of previous PCI9 patch
o Re-order <linux/fs.h> includes to fix userland breakage
o Fix NR_OPEN header order dependency
Trond Myklebust:
o NFS: Further fixes for the -onolock case
>This time it's really supposed to be a quickie, so people who can,
>please check it out, and we'll make the real 2.6.11 asap.
Out of diskspace on kernel.org?
http://www.kernel.org/pub/linux/kernel/v2.6/testing/
[...]
patch-2.6.11-rc5.bz2 23-Feb-2005 20:20 14
patch-2.6.11-rc5.bz2.sign 23-Feb-2005 20:20 248
patch-2.6.11-rc5.gz 23-Feb-2005 20:20 37
patch-2.6.11-rc5.gz.sign 23-Feb-2005 20:20 248
patch-2.6.11-rc5.sign 23-Feb-2005 20:20 248
Mvh
Mats Johannesson
--
Quoting Linus Torvalds ([email protected]):
>
>
> Hey, I hoped -rc4 was the last one, but we had some laptop resource
> conflicts, various ppc TLB flush issues, some possible stack overflows in
> networking and a number of other details warranting a quick -rc5 before
> the final 2.6.11.
>
> This time it's really supposed to be a quickie, so people who can, please
> check it out, and we'll make the real 2.6.11 asap.
>
> Mostly pretty small changes (the largest is a new SATA driver that crept
> in, our bad). But worth another quick round.
Are you sure you uploaded the correct patch file ?
-rw-rw-r-- 1 536 536 50907 Feb 24 04:13 ChangeLog-2.6.11-rc5
-rw-rw-r-- 1 536 536 0 Feb 24 04:13 LATEST-IS-2.6.11-rc5
-rw-rw-r-- 1 536 536 46586159 Feb 24 04:20 linux-2.6.11-rc5.tar.gz
-rw-rw-r-- 1 536 536 248 Feb 24 04:20 linux-2.6.11-rc5.tar.gz.sign
-rw-rw-r-- 1 536 536 37 Feb 24 04:20 patch-2.6.11-rc5.gz
-rw-rw-r-- 1 536 536 37080033 Feb 24 04:20 linux-2.6.11-rc5.tar.bz2
-rw-rw-r-- 1 536 536 248 Feb 24 04:20 linux-2.6.11-rc5.tar.bz2.sign
-rw-rw-r-- 1 536 536 248 Feb 24 04:20 linux-2.6.11-rc5.tar.sign
-rw-rw-r-- 1 536 536 14 Feb 24 04:20 patch-2.6.11-rc5.bz2
-rw-rw-r-- 1 536 536 248 Feb 24 04:20 patch-2.6.11-rc5.bz2.sign
-rw-rw-r-- 1 536 536 248 Feb 24 04:20 patch-2.6.11-rc5.gz.sign
-rw-rw-r-- 1 536 536 248 Feb 24 04:20 patch-2.6.11-rc5.sign
drwxrwsr-x 2 536 536 8192 Feb 24 04:57 incr
drwxrwsr-x 4 536 536 16384 Feb 24 05:00 .
lftp ftp.kernel.org:/pub/linux/kernel/v2.6/testing>
Cheers
Mike
On Wed, Feb 23, 2005 at 08:18:08PM -0800, Linus Torvalds wrote:
>
>
> Hey, I hoped -rc4 was the last one, but we had some laptop resource
> conflicts, various ppc TLB flush issues, some possible stack overflows in
> networking and a number of other details warranting a quick -rc5 before
> the final 2.6.11.
>
> This time it's really supposed to be a quickie, so people who can, please
> check it out, and we'll make the real 2.6.11 asap.
>
> Mostly pretty small changes (the largest is a new SATA driver that crept
> in, our bad). But worth another quick round.
Very small.
[ ] patch-2.6.11-rc5.bz2 23-Feb-2005 20:20 14
[ ] patch-2.6.11-rc5.bz2.sign 23-Feb-2005 20:20 248
[ ] patch-2.6.11-rc5.gz 23-Feb-2005 20:20 37
[ ] patch-2.6.11-rc5.gz.sign 23-Feb-2005 20:20 248
[ ] patch-2.6.11-rc5.sign 23-Feb-2005 20:20 248
Seems to have passed the gpg signature test on my end.
--
Mathematics is the supreme nostalgia of our time.
Matt Mackall wrote:
>On Wed, Feb 23, 2005 at 08:18:08PM -0800, Linus Torvalds wrote:
>
>
>>Hey, I hoped -rc4 was the last one, but we had some laptop resource
>>conflicts, various ppc TLB flush issues, some possible stack overflows in
>>networking and a number of other details warranting a quick -rc5 before
>>the final 2.6.11.
>>
>>This time it's really supposed to be a quickie, so people who can, please
>>check it out, and we'll make the real 2.6.11 asap.
>>
>>Mostly pretty small changes (the largest is a new SATA driver that crept
>>in, our bad). But worth another quick round.
>>
>>
>
>Very small.
>
>[ ] patch-2.6.11-rc5.bz2 23-Feb-2005 20:20 14
>[ ] patch-2.6.11-rc5.bz2.sign 23-Feb-2005 20:20 248
>[ ] patch-2.6.11-rc5.gz 23-Feb-2005 20:20 37
>[ ] patch-2.6.11-rc5.gz.sign 23-Feb-2005 20:20 248
>[ ] patch-2.6.11-rc5.sign 23-Feb-2005 20:20 248
>
>Seems to have passed the gpg signature test on my end.
>
>
>
The file seems to be empty.
Matthias-Christian Ott
On Thu, 2005-02-24 at 13:49 +0100, Matthias-Christian Ott wrote:
> Matt Mackall wrote:
> >Very small.
> >
> >[ ] patch-2.6.11-rc5.bz2 23-Feb-2005 20:20 14
> >[ ] patch-2.6.11-rc5.bz2.sign 23-Feb-2005 20:20 248
> >[ ] patch-2.6.11-rc5.gz 23-Feb-2005 20:20 37
> >[ ] patch-2.6.11-rc5.gz.sign 23-Feb-2005 20:20 248
> >[ ] patch-2.6.11-rc5.sign 23-Feb-2005 20:20 248
> >
> >Seems to have passed the gpg signature test on my end.
> >
> >
> >
> The file seems to be empty.
Anyone know if the linux-2.6.11-rc5.tar.bz2 has all the changes in it?
The tarball rc5 is smaller than rc4. Was there a lot taken out?
-- Steve
Steven Rostedt wrote:
> [...]
>
> Anyone know if the linux-2.6.11-rc5.tar.bz2 has all the changes in it?
> The tarball rc5 is smaller than rc4. Was there a lot taken out?
Take a look at the diffview of 2.6.11-rc4-rc5 incremental patch.
<snip>
5599 files changed, 166396 insertions(+), 293627 deletions(-)
</snip>
>
> -- Steve
>
>
--
M.Baris Demiray -- Labris Teknoloji
On Wed, Feb 23, Linus Torvalds wrote:
> This time it's really supposed to be a quickie, so people who can, please
> check it out, and we'll make the real 2.6.11 asap.
radeonfb oopses on intel.
Havent checked yet when it started with it.
ACPI: PCI interrupt 0000:00:12.0[A] -> GSI 11 (level, low) -> IRQ 11
eth0: VIA Rhine II at 0x1c400, 00:11:5b:83:1e:76, IRQ 11.
eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1.
usb 5-1: new low speed USB device using uhci_hcd and address 2
ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=133.00 Mhz, System=133.00 MHz
radeonfb: PLL min 12000 max 35000
NET: Registered protocol family 23
radeonfb: Monitor 1 type DFP found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
radeonfb: Assuming panel size 8x1
radeonfb: Can't find mode for panel size, going back to CRT
Unable to handle kernel paging request at virtual address f3fb4000
printing eip:
c01dec14
*pde = 00000000
Oops: 0002 [#1]
Modules linked in: via_ircc irda crc_ccitt snd_via82xx snd_ac97_codec snd_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore radeonfb i2c_algo_bit i2c_core via_rhine mii pci_hotplug ohci1394 ehci_hcd ieee1394 uhci_hcd via_agp agpgart usbcore reiserfs dm_mod ext3 jbd
CPU: 0
EIP: 0060:[<c01dec14>] Not tainted VLI
EFLAGS: 00010202 (2.6.11-rc4-bk10-200502230204-usbtest)
EIP is at cfb_imageblit+0x364/0x610
eax: 00000000 ebx: f3fb4004 ecx: 00000000 edx: f3fb4000
esi: 00000004 edi: df282000 ebp: 00000007 esp: dbef1c1c
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 3180, threadinfo=dbef0000 task=da303580)
Stack: 00000001 00000008 00000001 00000008 00000001 c04a7428 0000000a da302628
c011b293 00000046 da36e23c da36e000 00000046 0000051f c01043cf c0102eca
0000051f 1c46ece9 0000002b c036a2c0 df282000 00000000 0000000f 00000001
Call Trace:
[<c011b293>] __do_softirq+0x43/0xa0
[<c01043cf>] do_IRQ+0x1f/0x30
[<c0102eca>] common_interrupt+0x1a/0x20
[<c01dd570>] soft_cursor+0x190/0x200
[<c01d9124>] bit_cursor+0x464/0x4e0
[<c011edbf>] msleep+0x2f/0x40
[<c01d4e18>] fbcon_cursor+0x1a8/0x280
[<c020eac8>] hide_cursor+0x18/0x30
[<c020edd4>] redraw_screen+0x174/0x200
[<c01d3caa>] fbcon_prepare_logo+0x39a/0x3a0
[<c01d47b0>] fbcon_init+0x260/0x300
[<c020ef69>] visual_init+0xe9/0x170
[<c02125e6>] take_over_console+0x176/0x350
[<c01d38da>] fbcon_takeover+0x5a/0x90
[<c01d846a>] fbcon_fb_registered+0x5a/0x70
[<c01d8542>] fbcon_event_notify+0x52/0x80
[<c0121898>] notifier_call_chain+0x18/0x30
[<c01da667>] register_framebuffer+0xd7/0x150
[<c0117713>] release_console_sem+0x13/0x90
[<c017f7c7>] sysfs_new_dirent+0x17/0x60
[<c017f820>] sysfs_make_dirent+0x10/0x70
[<c017f59a>] sysfs_add_file+0x3a/0x60
[<e0c4a698>] radeonfb_pci_register+0x308/0x510 [radeonfb]
[<c01ce482>] pci_device_probe_static+0x32/0x50
[<c01ce4c7>] __pci_device_probe+0x27/0x40
[<c01ce4fb>] pci_device_probe+0x1b/0x40
[<c021ef31>] driver_probe_device+0x21/0x60
[<c021f05d>] driver_attach+0x4d/0x80
[<c021f44d>] bus_add_driver+0x6d/0xa0
[<c021f948>] driver_register+0x28/0x30
[<c01ce6c4>] pci_register_driver+0x54/0x70
[<c012b1a2>] sys_init_module+0x112/0x190
[<c0102c49>] sysenter_past_esp+0x52/0x79
Code: 24 60 8b 54 24 58 29 ce 0f be 07 89 f1 d3 f8 21 d0 8b 54 24 4c 8b 4c 24 54 23 0c 82 8b 54 24 64 89 c8 31 d0 89 da 83 c3 04 85 f6 <89> 02 75 06 be 08 00 00 00 47 8b 04 24 48 89 04 24 83 3c 24 ff
<6>usbcore: registered new driver hiddev
input: USB HID v1.10 Mouse [Logitech Apple Optical USB Mouse] on usb-0000:00:10.2-1
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
Linux 2.6 Compile Statistics (gcc 3.4.1)
Web page with links to complete details:
http://developer.osdl.org/cherry/compile/
Kernel bzImage bzImage bzImage modules bzImage modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
----------- ----------- -------- -------- -------- -------- ---------
2.6.11-rc5 14w/0e 0w/0e 353w/0e 6w/0e 18w/0e 431w/0e
2.6.11-rc4 14w/0e 0w/0e 353w/0e 6w/0e 18w/0e 431w/0e
2.6.11-rc3 14w/0e 0w/0e 356w/0e 6w/0e 18w/0e 435w/0e
2.6.11-rc3 13w/0e 0w/0e 356w/0e 6w/0e 18w/0e 435w/0e
2.6.11-rc2 18w/0e 0w/0e 365w/0e 6w/0e 22w/0e 440w/0e
2.6.11-rc1 20w/0e 0w/0e 497w/0e 6w/0e 22w/0e 577w/0e
2.6.10 13w/0e 0w/0e 778w/0e 6w/0e 15w/0e 861w/0e
2.6.9-rc3 13w/0e 0w/0e 774w/0e 6w/0e 15w/0e 857w/0e
2.6.9-rc2 14w/0e 0w/0e 1815w/11e 65w/0e 19w/0e 2157w/0e
(Compiles with gcc 3.2.2)
2.6.9-rc1 5w/0e 1w/0e 1069w/15e 6w/0e 4w/0e 1062w/1e
2.6.9 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
2.6.9-final 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
2.6.9-rc4 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
2.6.9-rc3 0w/0e 0w/0e 2752w/17e 41w/0e 11w/0e 2782w/5e
2.6.9-rc2 0w/0e 0w/0e 3036w/0e 41w/0e 11w/0e 3655w/0e
2.6.9-rc1 0w/0e 0w/0e 77w/10e 4w/0e 3w/0e 68w/0e
2.6.8.1 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8-rc4 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8-rc3 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8-rc2 0w/0e 0w/0e 85w/ 0e 5w/0e 1w/0e 79w/0e
2.6.8-rc1 0w/0e 0w/0e 87w/ 0e 5w/0e 1w/0e 82w/0e
2.6.7 0w/0e 0w/0e 108w/ 0e 5w/0e 2w/0e 102w/0e
2.6.7-rc3 0w/0e 0w/0e 108w/ 0e 5w/0e 2w/0e 104w/0e
2.6.7-rc2 0w/0e 0w/0e 110w/ 0e 5w/0e 2w/0e 106w/0e
2.6.7-rc1 0w/0e 0w/0e 111w/ 0e 6w/0e 2w/0e 107w/0e
2.6.6 0w/0e 0w/0e 123w/ 0e 7w/0e 4w/0e 121w/0e
2.6.6-rc3 0w/0e 0w/0e 124w/ 0e 7w/0e 5w/0e 121w/0e
2.6.6-rc2 0w/0e 0w/0e 122w/ 0e 7w/0e 4w/0e 121w/0e
2.6.6-rc1 0w/0e 0w/0e 125w/ 0e 7w/0e 4w/0e 123w/0e
2.6.5 0w/0e 0w/0e 134w/ 0e 8w/0e 4w/0e 132w/0e
2.6.5-rc3 0w/0e 0w/0e 135w/ 0e 8w/0e 4w/0e 132w/0e
2.6.5-rc2 0w/0e 0w/0e 135w/ 0e 8w/0e 3w/0e 132w/0e
2.6.5-rc1 0w/0e 0w/0e 138w/ 0e 8w/0e 3w/0e 135w/0e
2.6.4 1w/0e 0w/0e 145w/ 0e 7w/0e 3w/0e 142w/0e
2.6.4-rc2 1w/0e 0w/0e 148w/ 0e 7w/0e 3w/0e 145w/0e
2.6.4-rc1 1w/0e 0w/0e 148w/ 0e 7w/0e 3w/0e 145w/0e
2.6.3 1w/0e 0w/0e 142w/ 0e 9w/0e 3w/0e 142w/0e
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
Daily compiles (ia32):
http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt
Latest changes in Linus' bitkeeper tree:
http://linux.bkbits.net:8080/linux-2.5
John
On Thu, Feb 24, 2005 at 04:57:56PM +0200, M.Baris Demiray wrote:
>
> Steven Rostedt wrote:
>
> >[...]
> >
> >Anyone know if the linux-2.6.11-rc5.tar.bz2 has all the changes in it?
> >The tarball rc5 is smaller than rc4. Was there a lot taken out?
>
> Take a look at the diffview of 2.6.11-rc4-rc5 incremental patch.
>
> <snip>
> 5599 files changed, 166396 insertions(+), 293627 deletions(-)
> </snip>
Wow! Over 100 thousand lines removed!
If true, color me impressed, and kudos
to the developers.
Small is beautiful, I really like this :-)
Gabriel
On Thu, 24 Feb 2005 16:57:56 +0200 M.Baris Demiray wrote:
> Steven Rostedt wrote:
>
> > [...]
> >
> > Anyone know if the linux-2.6.11-rc5.tar.bz2 has all the changes in it?
> > The tarball rc5 is smaller than rc4. Was there a lot taken out?
>
> Take a look at the diffview of 2.6.11-rc4-rc5 incremental patch.
>
> <snip>
> 5599 files changed, 166396 insertions(+), 293627 deletions(-)
> </snip>
And especially at this chunk:
--- linux-2.6.11-rc4/Makefile 2005-02-23 20:53:50.707759849 -0800
+++ linux-2.6.11-rc5/Makefile 2004-12-24 13:35:01.000000000 -0800
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
-SUBLEVEL = 11
-EXTRAVERSION =-rc4
+SUBLEVEL = 10
+EXTRAVERSION =
NAME=Woozy Numbat
# *DOCUMENTATION*
Obviously 2.6.11-rc5 is screwed up.
On Thu, 24 Feb 2005, Michael Neuffer wrote:
>
> Are you sure you uploaded the correct patch file ?
Yes, I uploaded the "correct" file, but I had broken my release-script,
and that file was broken and empty.
Will fix, sorry,
Linus
On Thu, 2005-02-24 at 18:39 +0300, Sergey Vlasov wrote:
> On Thu, 24 Feb 2005 16:57:56 +0200 M.Baris Demiray wrote:
> And especially at this chunk:
>
> --- linux-2.6.11-rc4/Makefile 2005-02-23 20:53:50.707759849 -0800
> +++ linux-2.6.11-rc5/Makefile 2004-12-24 13:35:01.000000000 -0800
> @@ -1,7 +1,7 @@
> VERSION = 2
> PATCHLEVEL = 6
> -SUBLEVEL = 11
> -EXTRAVERSION =-rc4
> +SUBLEVEL = 10
> +EXTRAVERSION =
> NAME=Woozy Numbat
> # *DOCUMENTATION*
>
> Obviously 2.6.11-rc5 is screwed up.
Yeah, but the linux-2.6.11-rc5.tar.bz2's Makefile has
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 11
EXTRAVERSION =-rc5
NAME=Woozy Numbat
-- Steve
Linus Torvalds wrote:
>
> Hey, I hoped -rc4 was the last one, but we had some laptop resource
> conflicts, various ppc TLB flush issues, some possible stack overflows in
> networking and a number of other details warranting a quick -rc5 before
> the final 2.6.11.
>
> This time it's really supposed to be a quickie, so people who can, please
> check it out, and we'll make the real 2.6.11 asap.
>
> Mostly pretty small changes (the largest is a new SATA driver that crept
> in, our bad). But worth another quick round.
>
> Linus
>
> ----
It looks like the v2.6.11-rc5 tag is on the same revisions as 2.6.10.
patch-2.6.11-rc5 is an empty file, and patch-2.6.11-rc4-rc5 indicates
that 2.6.11-rc5 reverted to 2.6.10:
diff -urN linux-2.6.11-rc4/Makefile linux-2.6.11-rc5/Makefile
--- linux-2.6.11-rc4/Makefile 2005-02-23 20:53:50.707759849 -0800
+++ linux-2.6.11-rc5/Makefile 2004-12-24 13:35:01.000000000 -0800
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
-SUBLEVEL = 11
-EXTRAVERSION =-rc4
+SUBLEVEL = 10
+EXTRAVERSION =
NAME=Woozy Numbat
# *DOCUMENTATION*
--
Brian Gerst
On Thu, 24 Feb 2005, Brian Gerst wrote:
>
> It looks like the v2.6.11-rc5 tag is on the same revisions as 2.6.10.
> patch-2.6.11-rc5 is an empty file, and patch-2.6.11-rc4-rc5 indicates
> that 2.6.11-rc5 reverted to 2.6.10:
The correct -rc5 patch (as opposed to the empty one) should be there now.
It might take a bit of time for mirrors and the automated scripts to
notice.
(And I fixed my release-script)
Linus
On Thu, Feb 24, Olaf Hering wrote:
> On Wed, Feb 23, Linus Torvalds wrote:
>
> > This time it's really supposed to be a quickie, so people who can, please
> > check it out, and we'll make the real 2.6.11 asap.
>
> radeonfb oopses on intel.
> Havent checked yet when it started with it.
2.6.10 works at least.
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8378 [KM400/A] Chipset Host Bridge
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
0000:00:0a.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61)
0000:00:0a.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61)
0000:00:0a.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 62)
0000:00:0a.3 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46)
0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
0000:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]
Linux version 2.6.10-200502230204-usbtest (olaf@weissichgradnich) (gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)) #2 Thu Feb 24 17:56:06 CET 2005
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS)
BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
511MB LOWMEM available.
On node 0 totalpages: 131056
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 126960 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
DMI 2.2 present.
ACPI: RSDP (v000 KM400 ) @ 0x000f6cd0
ACPI: RSDT (v001 KM400 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3000
ACPI: FADT (v001 KM400 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040
ACPI: MADT (v001 KM400 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff7a40
ACPI: DSDT (v001 KM400 AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x00000000
ACPI: PM-Timer IO Port: 0x4008
Built 1 zonelists
Kernel command line: vga=normal selinux=0 panic=180
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 1328.010 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 513340k/524224k available (2149k kernel code, 10296k reserved, 1155k data, 204k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 2621.44 BogoMIPS (lpj=1310720)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0383fbff c1cbfbff 00000000 00000000
CPU: After vendor identify, caps: 0383fbff c1cbfbff 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps: 0383fbff c1cbfbff 00000000 00000020
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Sempron(tm) stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0e28)
checking if image is initramfs... it is
Freeing initrd memory: 1100k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb5e0, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20041105
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 10 *11 12)
ACPI: PCI Interrupt Link [LNKB] (IRQs *3 4 6 7 10 11 12)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 *10 11 12)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 11 12) *5
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 7 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 6 7 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 6 7 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [ALKA] (IRQs 20) *0, disabled.
ACPI: PCI Interrupt Link [ALKB] (IRQs 21) *0, disabled.
ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *0, disabled.
ACPI: PCI Interrupt Link [ALKD] (IRQs 23) *0, disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 10 devices
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically. If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device(). As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior. If this argument makes the device work again,
** please email the output of "lspci" to [email protected]
** so I can fix the driver.
TC classifier action (bugs to [email protected] cc [email protected])
pnp: 00:01: ioport range 0x4000-0x407f could not be reserved
pnp: 00:01: ioport range 0x5000-0x500f has been reserved
Machine check exception polling timer started.
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
apm: overridden by ACPI.
audit: initializing netlink socket (disabled)
audit(1109264817.884:0): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
vesafb: probe of vesafb0 failed with error -6
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
elevator: using anticipatory as default io scheduler
floppy0: no floppy controllers found
RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 blocksize
loop: loaded (max 8 devices)
via-rhine.c:v1.10-LK1.2.0-2.6 June-10-2004 Written by Donald Becker
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI interrupt 0000:00:12.0[A] -> GSI 11 (level, low) -> IRQ 11
eth0: VIA Rhine II at 0xc400, 00:11:5b:83:1e:76, IRQ 11.
eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:11.1
ACPI: PCI interrupt 0000:00:11.1[A] -> GSI 11 (level, low) -> IRQ 11
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci0000:00:11.1
ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xb808-0xb80f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: SAMSUNG SP1203N, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
Probing IDE interface ide1...
Probing IDE interface ide2...
ide2: Wait for ready failed before probe !
Probing IDE interface ide3...
ide3: Wait for ready failed before probe !
Probing IDE interface ide4...
ide4: Wait for ready failed before probe !
Probing IDE interface ide5...
ide5: Wait for ready failed before probe !
hda: max request size: 1024KiB
hda: Host Protected Area detected.
current capacity is 66055248 sectors (33820 MB)
native capacity is 234493056 sectors (120060 MB)
hda: Host Protected Area disabled.
hda: 234493056 sectors (120060 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
hda: hda1 hda2 < hda5 hda6 hda7 hda8 >
ide-floppy driver 0.99.newide
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
input: PC Speaker
md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET: Registered protocol family 1
ACPI wakeup devices:
PCI0 USB0 USB1 USB2 USB6 USB7 USB8 USB9 LAN0 MC97 UAR1 ECP1
ACPI: (supports S0 S1 S4 S5)
Freeing unused kernel memory: 204k freed
ide_core: disagrees about version of symbol struct_module
via82cxxx: disagrees about version of symbol struct_module
jbd: disagrees about version of symbol struct_module
ext3: disagrees about version of symbol struct_module
ide_disk: disagrees about version of symbol struct_module
ide_floppy: disagrees about version of symbol struct_module
cdrom: disagrees about version of symbol struct_module
ide_cd: disagrees about version of symbol struct_module
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
EXT3 FS on hda8, internal journal
device-mapper: 4.3.0-ioctl (2004-09-30) initialised: [email protected]
ReiserFS: hda1: found reiserfs format "3.6" with standard journal
ReiserFS: hda1: using ordered data mode
ReiserFS: hda1: journal params: device hda1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda1: checking transaction log (hda1)
ReiserFS: hda1: Using r5 hash to sort names
ReiserFS: hda7: found reiserfs format "3.6" with standard journal
ReiserFS: hda7: using ordered data mode
ReiserFS: hda7: journal params: device hda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda7: checking transaction log (hda7)
ReiserFS: hda7: Using r5 hash to sort names
ReiserFS: hda6: found reiserfs format "3.6" with standard journal
ReiserFS: hda6: using ordered data mode
ReiserFS: hda6: journal params: device hda6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda6: checking transaction log (hda6)
ReiserFS: hda6: Using r5 hash to sort names
ReiserFS: hda5: found reiserfs format "3.6" with standard journal
ReiserFS: hda5: using ordered data mode
ReiserFS: hda5: journal params: device hda5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda5: checking transaction log (hda5)
ReiserFS: hda5: Using r5 hash to sort names
Linux agpgart interface v0.100 (c) Dave Jones
cpci_hotplug: CompactPCI Hot Plug Core version: 0.2
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v2.2
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI interrupt 0000:00:0a.0[A] -> GSI 10 (level, low) -> IRQ 10
uhci_hcd 0000:00:0a.0: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5
shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x5
uhci_hcd 0000:00:0a.0: irq 10, io base 0xa000
uhci_hcd 0000:00:0a.0: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
ACPI: PCI interrupt 0000:00:0a.1[B] -> GSI 11 (level, low) -> IRQ 11
PCI: Via IRQ fixup for 0000:00:0a.1, from 5 to 11
uhci_hcd 0000:00:0a.1: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#2)
uhci_hcd 0000:00:0a.1: irq 11, io base 0xa400
uhci_hcd 0000:00:0a.1: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:10.0[A] -> GSI 11 (level, low) -> IRQ 11
uhci_hcd 0000:00:10.0: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#3)
uhci_hcd 0000:00:10.0: irq 11, io base 0xac00
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 3
PCI: setting IRQ 3 as level-triggered
ACPI: PCI interrupt 0000:00:10.1[B] -> GSI 3 (level, low) -> IRQ 3
uhci_hcd 0000:00:10.1: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#4)
uhci_hcd 0000:00:10.1: irq 3, io base 0xb000
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:10.2[C] -> GSI 10 (level, low) -> IRQ 10
uhci_hcd 0000:00:10.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#5)
uhci_hcd 0000:00:10.2: irq 10, io base 0xb400
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 5
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
agpgart: Detected VIA KM400/KM400A chipset
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 128M @ 0xd0000000
ACPI: PCI interrupt 0000:00:0a.2[C] -> GSI 11 (level, low) -> IRQ 11
ehci_hcd 0000:00:0a.2: VIA Technologies, Inc. USB 2.0
ehci_hcd 0000:00:0a.2: irq 11, pci mem 0xe2000000
ehci_hcd 0000:00:0a.2: new USB bus registered, assigned bus number 6
ehci_hcd 0000:00:0a.2: USB 2.0 initialized, EHCI 1.00, driver 26 Oct 2004
hub 6-0:1.0: USB hub found
hub 6-0:1.0: 4 ports detected
ACPI: PCI interrupt 0000:00:10.3[D] -> GSI 11 (level, low) -> IRQ 11
ehci_hcd 0000:00:10.3: VIA Technologies, Inc. USB 2.0 (#2)
ehci_hcd 0000:00:10.3: irq 11, pci mem 0xe2002000
ehci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 7
ehci_hcd 0000:00:10.3: USB 2.0 initialized, EHCI 1.00, driver 26 Oct 2004
hub 7-0:1.0: USB hub found
hub 7-0:1.0: 6 ports detected
ieee1394: Initialized config rom entry `ip1394'
ohci1394: $Rev: 1223 $ Ben Collins <[email protected]>
ACPI: PCI interrupt 0000:00:0a.3[A] -> GSI 10 (level, low) -> IRQ 10
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[10] MMIO=[e2001000-e20017ff] Max Packet=[2048]
via82xx: Assuming DXS channels with 48k fixed sample rate.
Please try dxs_support=1 or dxs_support=4 option
and report if it works on your machine.
ACPI: PCI interrupt 0000:00:11.5[C] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:00:11.5 to 64
NET: Registered protocol family 23
ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=133.00 Mhz, System=133.00 MHz
radeonfb: PLL min 12000 max 35000
usb 5-1: new low speed USB device using uhci_hcd and address 2
ieee1394: Host added: ID:BUS[0-00:1023] GUID[0011060000006685]
radeonfb: Monitor 1 type DFP found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
EDID checksum failed, aborting
EDID checksum failed, aborting
EDID checksum failed, aborting
radeonfb: Assuming panel size 8x1
radeonfb: Can't find mode for panel size, going back to CRT
Console: switching to colour frame buffer device 80x30
radeonfb: ATI Radeon QY DDR SGRAM 64 MB
usbcore: registered new driver hiddev
input: USB HID v1.10 Mouse [Logitech Apple Optical USB Mouse] on usb-0000:00:10.2-1
usbcore: registered new driver usbhid
/home/olaf/linux-2.6.10/drivers/usb/input/hid-core.c: v2.0:USB HID core driver
SCSI subsystem initialized
st: Version 20041025, fixed bufsize 32768, s/g segs 256
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
NET: Registered protocol family 17
ACPI: Power Button (FF) [PWRF]
ACPI: Fan [FAN] (on)
ACPI: Processor [CPU0] (supports C1 C2)
ACPI: Thermal Zone [THRM] (39 C)
NET: Registered protocol family 10
Disabled Privacy Extensions on device c03c0940(lo)
IPv6 over IPv4 tunneling driver
Disabled Privacy Extensions on device daf4d400(sit0)
powernow-k8: Processor cpuid 681 not supported
On Thu, 2005-02-24 at 15:50 +0100, Olaf Hering wrote:
> On Wed, Feb 23, Linus Torvalds wrote:
>
> > This time it's really supposed to be a quickie, so people who can, please
> > check it out, and we'll make the real 2.6.11 asap.
>
> radeonfb oopses on intel.
> Havent checked yet when it started with it.
>
> ACPI: PCI interrupt 0000:00:12.0[A] -> GSI 11 (level, low) -> IRQ 11
> eth0: VIA Rhine II at 0x1c400, 00:11:5b:83:1e:76, IRQ 11.
> eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1.
> usb 5-1: new low speed USB device using uhci_hcd and address 2
> ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
> radeonfb: Found Intel x86 BIOS ROM Image
> radeonfb: Retreived PLL infos from BIOS
> radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=133.00 Mhz, System=133.00 MHz
> radeonfb: PLL min 12000 max 35000
> NET: Registered protocol family 23
> radeonfb: Monitor 1 type DFP found
> radeonfb: EDID probed
> radeonfb: Monitor 2 type no found
> radeonfb: Assuming panel size 8x1
Hrm... that's totally bogus. What machine is this ?
> radeonfb: Can't find mode for panel size, going back to CRT
> Unable to handle kernel paging request at virtual address f3fb4000
I'm having a hard time parsing this oops. Looks like fbcon is screwing
up, I'm not sure what radeonfb has to do with the problem there...
Ben.
> printing eip:
> c01dec14
> *pde = 00000000
> Oops: 0002 [#1]
> Modules linked in: via_ircc irda crc_ccitt snd_via82xx snd_ac97_codec snd_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore radeonfb i2c_algo_bit i2c_core via_rhine mii pci_hotplug ohci1394 ehci_hcd ieee1394 uhci_hcd via_agp agpgart usbcore reiserfs dm_mod ext3 jbd
> CPU: 0
> EIP: 0060:[<c01dec14>] Not tainted VLI
> EFLAGS: 00010202 (2.6.11-rc4-bk10-200502230204-usbtest)
> EIP is at cfb_imageblit+0x364/0x610
> eax: 00000000 ebx: f3fb4004 ecx: 00000000 edx: f3fb4000
> esi: 00000004 edi: df282000 ebp: 00000007 esp: dbef1c1c
> ds: 007b es: 007b ss: 0068
> Process modprobe (pid: 3180, threadinfo=dbef0000 task=da303580)
> Stack: 00000001 00000008 00000001 00000008 00000001 c04a7428 0000000a da302628
> c011b293 00000046 da36e23c da36e000 00000046 0000051f c01043cf c0102eca
> 0000051f 1c46ece9 0000002b c036a2c0 df282000 00000000 0000000f 00000001
> Call Trace:
> [<c011b293>] __do_softirq+0x43/0xa0
> [<c01043cf>] do_IRQ+0x1f/0x30
> [<c0102eca>] common_interrupt+0x1a/0x20
> [<c01dd570>] soft_cursor+0x190/0x200
> [<c01d9124>] bit_cursor+0x464/0x4e0
> [<c011edbf>] msleep+0x2f/0x40
> [<c01d4e18>] fbcon_cursor+0x1a8/0x280
> [<c020eac8>] hide_cursor+0x18/0x30
> [<c020edd4>] redraw_screen+0x174/0x200
> [<c01d3caa>] fbcon_prepare_logo+0x39a/0x3a0
> [<c01d47b0>] fbcon_init+0x260/0x300
> [<c020ef69>] visual_init+0xe9/0x170
> [<c02125e6>] take_over_console+0x176/0x350
> [<c01d38da>] fbcon_takeover+0x5a/0x90
> [<c01d846a>] fbcon_fb_registered+0x5a/0x70
> [<c01d8542>] fbcon_event_notify+0x52/0x80
> [<c0121898>] notifier_call_chain+0x18/0x30
> [<c01da667>] register_framebuffer+0xd7/0x150
> [<c0117713>] release_console_sem+0x13/0x90
> [<c017f7c7>] sysfs_new_dirent+0x17/0x60
> [<c017f820>] sysfs_make_dirent+0x10/0x70
> [<c017f59a>] sysfs_add_file+0x3a/0x60
> [<e0c4a698>] radeonfb_pci_register+0x308/0x510 [radeonfb]
> [<c01ce482>] pci_device_probe_static+0x32/0x50
> [<c01ce4c7>] __pci_device_probe+0x27/0x40
> [<c01ce4fb>] pci_device_probe+0x1b/0x40
> [<c021ef31>] driver_probe_device+0x21/0x60
> [<c021f05d>] driver_attach+0x4d/0x80
> [<c021f44d>] bus_add_driver+0x6d/0xa0
> [<c021f948>] driver_register+0x28/0x30
> [<c01ce6c4>] pci_register_driver+0x54/0x70
> [<c012b1a2>] sys_init_module+0x112/0x190
> [<c0102c49>] sysenter_past_esp+0x52/0x79
> Code: 24 60 8b 54 24 58 29 ce 0f be 07 89 f1 d3 f8 21 d0 8b 54 24 4c 8b 4c 24 54 23 0c 82 8b 54 24 64 89 c8 31 d0 89 da 83 c3 04 85 f6 <89> 02 75 06 be 08 00 00 00 47 8b 04 24 48 89 04 24 83 3c 24 ff
> <6>usbcore: registered new driver hiddev
> input: USB HID v1.10 Mouse [Logitech Apple Optical USB Mouse] on usb-0000:00:10.2-1
> usbcore: registered new driver usbhid
> drivers/usb/input/hid-core.c: v2.0:USB HID core driver
>
--
Benjamin Herrenschmidt <[email protected]>
On Fri, Feb 25, Benjamin Herrenschmidt wrote:
> On Thu, 2005-02-24 at 15:50 +0100, Olaf Hering wrote:
> > On Wed, Feb 23, Linus Torvalds wrote:
> >
> > > This time it's really supposed to be a quickie, so people who can, please
> > > check it out, and we'll make the real 2.6.11 asap.
> >
> > radeonfb oopses on intel.
> > Havent checked yet when it started with it.
> >
> > ACPI: PCI interrupt 0000:00:12.0[A] -> GSI 11 (level, low) -> IRQ 11
> > eth0: VIA Rhine II at 0x1c400, 00:11:5b:83:1e:76, IRQ 11.
> > eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1.
> > usb 5-1: new low speed USB device using uhci_hcd and address 2
> > ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
> > radeonfb: Found Intel x86 BIOS ROM Image
> > radeonfb: Retreived PLL infos from BIOS
> > radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=133.00 Mhz, System=133.00 MHz
> > radeonfb: PLL min 12000 max 35000
> > NET: Registered protocol family 23
> > radeonfb: Monitor 1 type DFP found
> > radeonfb: EDID probed
> > radeonfb: Monitor 2 type no found
> > radeonfb: Assuming panel size 8x1
>
> Hrm... that's totally bogus. What machine is this ?
Some i386 box with radeon 7000.
> > radeonfb: Can't find mode for panel size, going back to CRT
> > Unable to handle kernel paging request at virtual address f3fb4000
>
> I'm having a hard time parsing this oops. Looks like fbcon is screwing
> up, I'm not sure what radeonfb has to do with the problem there...
I will try with atyfb on another intel box.
On Fri, 2005-02-25 at 08:08 +0100, Olaf Hering wrote:
> On Fri, Feb 25, Benjamin Herrenschmidt wrote:
>
> > On Thu, 2005-02-24 at 15:50 +0100, Olaf Hering wrote:
> > > On Wed, Feb 23, Linus Torvalds wrote:
> > >
> > > > This time it's really supposed to be a quickie, so people who can, please
> > > > check it out, and we'll make the real 2.6.11 asap.
> > >
> > > radeonfb oopses on intel.
> > > Havent checked yet when it started with it.
> > >
> > > ACPI: PCI interrupt 0000:00:12.0[A] -> GSI 11 (level, low) -> IRQ 11
> > > eth0: VIA Rhine II at 0x1c400, 00:11:5b:83:1e:76, IRQ 11.
> > > eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1.
> > > usb 5-1: new low speed USB device using uhci_hcd and address 2
> > > ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
> > > radeonfb: Found Intel x86 BIOS ROM Image
> > > radeonfb: Retreived PLL infos from BIOS
> > > radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=133.00 Mhz, System=133.00 MHz
> > > radeonfb: PLL min 12000 max 35000
> > > NET: Registered protocol family 23
> > > radeonfb: Monitor 1 type DFP found
> > > radeonfb: EDID probed
> > > radeonfb: Monitor 2 type no found
> > > radeonfb: Assuming panel size 8x1
> >
> > Hrm... that's totally bogus. What machine is this ?
>
> Some i386 box with radeon 7000.
It seem to detect the flat panel incorrectly, or the EDID data is bogus,
maybe that's wrecking something in the new modelist management in
fbdev ? It might be causing us to use a bogus mode that itself casues
atyfb to crash. Tried forcing a mode ?
> > > radeonfb: Can't find mode for panel size, going back to CRT
> > > Unable to handle kernel paging request at virtual address f3fb4000
> >
> > I'm having a hard time parsing this oops. Looks like fbcon is screwing
> > up, I'm not sure what radeonfb has to do with the problem there...
>
> I will try with atyfb on another intel box.
--
Benjamin Herrenschmidt <[email protected]>
hi,
i also have problems with 2.6.11-rc5 and radeon:
i am using a ATI Radeon X600 PciExpress.
a) now the console framebuffer seems to bee working, thx benjamin :)
b) when bootup seq ist completed and i want to start X (xorg-x11) with ati-drivers
x is freezing - not your problem, but the console is not correctly restored :/ the only way
out is to reset the machine :/
2.6.11-rc3 was running fine in this case
i have attached my lspci -vv & lspci -tv output and following a small seq of the dmesg output
when initializing the radeon fb.
if i can provide/assit you with testing, i am available to do so, also if you need more information
on my system.
i am subscribed to lkml, but i would like to be included into cc seprately, thx.
radeonfb_pci_register BEGIN
ACPI: PCI interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
radeonfb (0000:05:00.0): Found 131072k of DDR 128 bits wide videoram
radeonfb (0000:05:00.0): mapped 16384k videoram
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=400.00 Mhz, System=300.00 MHz
radeonfb: PLL min 20000 max 40000
1 chips in connector info
- chip 1 has 2 connectors
* connector 0 of type 2 (CRT) : 2300
* connector 1 of type 3 (DVI-I) : 3221
Starting monitor auto detection...
radeonfb: I2C (port 1) ... not found
radeonfb: I2C (port 2) ... not found
radeonfb: I2C (port 3) ... found CRT display
radeonfb: I2C (port 4) ... not found
radeonfb: I2C (port 2) ... not found
radeonfb: I2C (port 4) ... not found
radeonfb: I2C (port 3) ... found CRT display
radeonfb: Monitor 1 type CRT found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
Display is GTF capable
hStart = 1344, hEnd = 1504, hTotal = 1728
vStart = 1025, vEnd = 1028, vTotal = 1072
h_total_disp = 0x9f00d7 hsync_strt_wid = 0x14054a
v_total_disp = 0x3ff042f vsync_strt_wid = 0x30400
pixclock = 6349
freq = 15750
freq = 15750, PLL min = 20000, PLL max = 40000
ref_div = 12, ref_clk = 2700, output_freq = 31500
ref_div = 12, ref_clk = 2700, output_freq = 31500
post div = 0x1
fb_div = 0x8c
ppll_div_3 = 0x1008c
Console: switching to colour frame buffer device 160x64
radeonfb (0000:05:00.0): ATI Radeon [b
radeonfb_pci_register END
In article <[email protected]> you write:
>
>
>Hey, I hoped -rc4 was the last one, but we had some laptop resource
>conflicts, various ppc TLB flush issues, some possible stack overflows in
>networking and a number of other details warranting a quick -rc5 before
>the final 2.6.11.
>
>This time it's really supposed to be a quickie, so people who can, please
>check it out, and we'll make the real 2.6.11 asap.
Hmmm. Also seems to have introduced a laptop conflict. Bluetooth no
longer survives a suspend/resume cycle.
IBM ThinkPad X31 (2884-JUU) using hci_usb. Bluetooth service is shut
down before suspend and restarted upon return. Works fine in rc4.
# lspci
0000:00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 03)
0000:00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 03)
0000:00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
0000:00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01)
0000:00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01)
0000:00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI Controller (rev 01)
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81)
0000:00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01)
0000:00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 01)
0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
0000:00:1f.6 Modem: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY
0000:02:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa)
0000:02:00.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa)
0000:02:00.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 02)
0000:02:01.0 Ethernet controller: Intel Corp. 82540EP Gigabit Ethernet Controller (Mobile) (rev 03)
0000:02:02.0 Ethernet controller: Atheros Communications, Inc. AR5211 802.11ab NIC (rev 01)
#
Unlike earlier problems (circa 2.6.10), the bluetooth LED comes back on,
but the drivers complain of no device available and socket in use.
Vince
--
Dr. Vincent C. Jones, PE Expert advice and a helping hand
Computer Network Consultant for those who want to manage and
Networking Unlimited, Inc. control their networking destiny
Phone: +1 201 568-7810
14 Dogwood Lane, Tenafly, NJ 07670
[email protected] http://www.networkingunlimited.com
On Fri, Feb 25, Benjamin Herrenschmidt wrote:
> On Fri, 2005-02-25 at 08:08 +0100, Olaf Hering wrote:
> > On Fri, Feb 25, Benjamin Herrenschmidt wrote:
> >
> > > On Thu, 2005-02-24 at 15:50 +0100, Olaf Hering wrote:
> > > > On Wed, Feb 23, Linus Torvalds wrote:
> > > >
> > > > > This time it's really supposed to be a quickie, so people who can, please
> > > > > check it out, and we'll make the real 2.6.11 asap.
> > > >
> > > > radeonfb oopses on intel.
> > > > Havent checked yet when it started with it.
> > > >
> > > > ACPI: PCI interrupt 0000:00:12.0[A] -> GSI 11 (level, low) -> IRQ 11
> > > > eth0: VIA Rhine II at 0x1c400, 00:11:5b:83:1e:76, IRQ 11.
> > > > eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1.
> > > > usb 5-1: new low speed USB device using uhci_hcd and address 2
> > > > ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
> > > > radeonfb: Found Intel x86 BIOS ROM Image
> > > > radeonfb: Retreived PLL infos from BIOS
> > > > radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=133.00 Mhz, System=133.00 MHz
> > > > radeonfb: PLL min 12000 max 35000
> > > > NET: Registered protocol family 23
> > > > radeonfb: Monitor 1 type DFP found
> > > > radeonfb: EDID probed
> > > > radeonfb: Monitor 2 type no found
> > > > radeonfb: Assuming panel size 8x1
> > >
> > > Hrm... that's totally bogus. What machine is this ?
> >
> > Some i386 box with radeon 7000.
>
> It seem to detect the flat panel incorrectly, or the EDID data is bogus,
> maybe that's wrecking something in the new modelist management in
> fbdev ? It might be causing us to use a bogus mode that itself casues
> atyfb to crash. Tried forcing a mode ?
cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
fast_imageblit(237) s daea4000 dst1 fa51a800
fast_imageblit(269) j 1 fa51a800 0
Unable to handle kernel paging request at virtual address fa51a800
is bitstart incorrect or is the thing just not (yet) mapped?
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=133.00 Mhz, System=133.00 MHz
radeonfb: PLL min 12000 max 35000
radeonfb: Monitor 1 type DFP found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
radeonfb: Assuming panel size 8x1
radeonfb: Can't find mode for panel size, going back to CRT
cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
fast_imageblit(237) s daea4000 dst1 fa51a800
fast_imageblit(269) j 1 fa51a800 0
Unable to handle kernel paging request at virtual address fa51a800
printing eip:
c020f17e
*pde = 00000000
Oops: 0002 [#1]
Modules linked in: ohci1394 ieee1394 radeonfb i2c_algo_bit i2c_core ehci_hcd uhci_hcd capability usbcore
CPU: 0
EIP: 0060:[<c020f17e>] Tainted: G U VLI
EFLAGS: 00010282 (2.6.11-rc5-20050225-default)
EIP is at cfb_imageblit+0x57e/0x67c
eax: 00000000 ebx: 00000001 ecx: 00000000 edx: fa51a800
esi: fa51a804 edi: daea4000 ebp: 00000004 esp: dcae9c14
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 2080, threadinfo=dcae8000 task=dc4a7550)
Stack: c01110ac 00000001 c0321d60 dcae9c20 dcae9c20 c01303a2 00000001 c03c87a8
0000000a dae23ca8 c011c783 00000046 00000000 dc202000 00000046 dcae9c64
c010513d 0000384d dc202290 00000007 c032db20 daea4000 00000000 0000000f
Call Trace:
[<c01110ac>] smp_local_timer_interrupt+0xc/0x50
[<c01303a2>] handle_IRQ_event+0x32/0x70
[<c011c783>] __do_softirq+0x43/0xa0
[<c010513d>] do_IRQ+0x3d/0x60
[<c020d790>] soft_cursor+0x190/0x200
[<c02043cc>] bit_cursor+0x48c/0x4f0
[<e0b26c01>] radeonfb_prim_fillrect+0xf1/0x120 [radeonfb]
[<c012043f>] msleep+0x2f/0x40
[<c01fff28>] fbcon_cursor+0x1a8/0x280
[<c023ad08>] hide_cursor+0x18/0x30
[<c023b014>] redraw_screen+0x174/0x200
[<c01fed4a>] fbcon_prepare_logo+0x39a/0x3a0
[<c01ff8a0>] fbcon_init+0x2b0/0x370
[<c023b1a9>] visual_init+0xe9/0x170
> cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
> fast_imageblit(237) s daea4000 dst1 fa51a800
> fast_imageblit(269) j 1 fa51a800 0
> Unable to handle kernel paging request at virtual address fa51a800
>
> is bitstart incorrect or is the thing just not (yet) mapped?
Looks like the screen_base is not mapped to.
On Fri, Feb 25, James Simmons wrote:
>
> > cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
> > fast_imageblit(237) s daea4000 dst1 fa51a800
> > fast_imageblit(269) j 1 fa51a800 0
> > Unable to handle kernel paging request at virtual address fa51a800
> >
> > is bitstart incorrect or is the thing just not (yet) mapped?
>
> Looks like the screen_base is not mapped to.
rc3 worked ok, rc4 does not. testing the -bk snapshots now.
On Fri, Feb 25, Olaf Hering wrote:
> On Fri, Feb 25, James Simmons wrote:
>
> >
> > > cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
> > > fast_imageblit(237) s daea4000 dst1 fa51a800
> > > fast_imageblit(269) j 1 fa51a800 0
> > > Unable to handle kernel paging request at virtual address fa51a800
> > >
> > > is bitstart incorrect or is the thing just not (yet) mapped?
> >
> > Looks like the screen_base is not mapped to.
>
> rc3 worked ok, rc4 does not. testing the -bk snapshots now.
bk8 works, bk9 breaks, it contains the radeonfb update.
it works ok if the driver is compiled into the kernel.
Linus Torvalds wrote:
>
> Hey, I hoped -rc4 was the last one, but we had some laptop resource
> conflicts, various ppc TLB flush issues, some possible stack overflows in
> networking and a number of other details warranting a quick -rc5 before
> the final 2.6.11.
>
> This time it's really supposed to be a quickie, so people who can, please
> check it out, and we'll make the real 2.6.11 asap.
>
> Mostly pretty small changes (the largest is a new SATA driver that crept
> in, our bad). But worth another quick round.
Three bugs down, one to go...
- backlight poweroff from screensaver: WORKING
- power off on shutdown: RELIABLE
- detection of the DVD drive without a disk in it at boot: WORKING
- sound: hasn't worked since FC1...
ASUS 1681 Pentium-M, 512MB, 80GB, 1400x1050 screen
FC1 worked, clean install FC2 had display issues, upgrade to FC3 doesn't
use full screen size and sound is totally NFG. I'm going to drop back to
oss over the weekend and see if that helps.
If anyone cares, the relevant lspci, dmesg, lsmod, etc, etc, are at
//216.238.38.194/nosound
and it will be up unless some development breaks it. I have posted this
elsewhere, could see attaching all the cruft to a message for the whole
list.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Fri, 2005-02-25 at 16:47 -0500, Bill Davidsen wrote:
> - sound: hasn't worked since FC1...
>
The ALSA lists have been deluged with reports like "sound worked in FC1,
upgraded to FC3, no sound". AFAICT it's just sloppiness on the part of
the Fedora userspace tools. For example, last I heard
system-config-soundcard tries to load the emu10k1 module for cards that
need the (completely different) emu10k1x driver.
Lee
On Fri, Feb 25, Olaf Hering wrote:
> On Fri, Feb 25, Olaf Hering wrote:
>
> > On Fri, Feb 25, James Simmons wrote:
> >
> > >
> > > > cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
> > > > fast_imageblit(237) s daea4000 dst1 fa51a800
> > > > fast_imageblit(269) j 1 fa51a800 0
> > > > Unable to handle kernel paging request at virtual address fa51a800
> > > >
> > > > is bitstart incorrect or is the thing just not (yet) mapped?
> > >
> > > Looks like the screen_base is not mapped to.
> >
> > rc3 worked ok, rc4 does not. testing the -bk snapshots now.
>
> bk8 works, bk9 breaks, it contains the radeonfb update.
> it works ok if the driver is compiled into the kernel.
modedb = rinfo->mon1_modedb; passes some shit to fb_find_mode() which
kills my screen(1) when DPRINTK is enabled. it dies because bitstart
relies on xres_virtual which is 0xcccccc or whatever.
On Thu, Feb 24, Olaf Hering wrote:
> On Wed, Feb 23, Linus Torvalds wrote:
>
> > This time it's really supposed to be a quickie, so people who can, please
> > check it out, and we'll make the real 2.6.11 asap.
>
> radeonfb oopses on intel.
> Havent checked yet when it started with it.
>
> ACPI: PCI interrupt 0000:00:12.0[A] -> GSI 11 (level, low) -> IRQ 11
> eth0: VIA Rhine II at 0x1c400, 00:11:5b:83:1e:76, IRQ 11.
> eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1.
> usb 5-1: new low speed USB device using uhci_hcd and address 2
> ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
> radeonfb: Found Intel x86 BIOS ROM Image
> radeonfb: Retreived PLL infos from BIOS
> radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=133.00 Mhz, System=133.00 MHz
> radeonfb: PLL min 12000 max 35000
> NET: Registered protocol family 23
> radeonfb: Monitor 1 type DFP found
> radeonfb: EDID probed
> radeonfb: Monitor 2 type no found
> radeonfb: Assuming panel size 8x1
> radeonfb: Can't find mode for panel size, going back to CRT
> Unable to handle kernel paging request at virtual address f3fb4000
> printing eip:
> c01dec14
> *pde = 00000000
> Oops: 0002 [#1]
> Modules linked in: via_ircc irda crc_ccitt snd_via82xx snd_ac97_codec snd_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore radeonfb i2c_algo_bit i2c_core via_rhine mii pci_hotplug ohci1394 ehci_hcd ieee1394 uhci_hcd via_agp agpgart usbcore reiserfs dm_mod ext3 jbd
> CPU: 0
> EIP: 0060:[<c01dec14>] Not tainted VLI
> EFLAGS: 00010202 (2.6.11-rc4-bk10-200502230204-usbtest)
> EIP is at cfb_imageblit+0x364/0x610
> eax: 00000000 ebx: f3fb4004 ecx: 00000000 edx: f3fb4000
> esi: 00000004 edi: df282000 ebp: 00000007 esp: dbef1c1c
> ds: 007b es: 007b ss: 0068
> Process modprobe (pid: 3180, threadinfo=dbef0000 task=da303580)
> Stack: 00000001 00000008 00000001 00000008 00000001 c04a7428 0000000a da302628
> c011b293 00000046 da36e23c da36e000 00000046 0000051f c01043cf c0102eca
> 0000051f 1c46ece9 0000002b c036a2c0 df282000 00000000 0000000f 00000001
> Call Trace:
> [<c011b293>] __do_softirq+0x43/0xa0
> [<c01043cf>] do_IRQ+0x1f/0x30
> [<c0102eca>] common_interrupt+0x1a/0x20
> [<c01dd570>] soft_cursor+0x190/0x200
> [<c01d9124>] bit_cursor+0x464/0x4e0
> [<c011edbf>] msleep+0x2f/0x40
> [<c01d4e18>] fbcon_cursor+0x1a8/0x280
> [<c020eac8>] hide_cursor+0x18/0x30
> [<c020edd4>] redraw_screen+0x174/0x200
> [<c01d3caa>] fbcon_prepare_logo+0x39a/0x3a0
> [<c01d47b0>] fbcon_init+0x260/0x300
> [<c020ef69>] visual_init+0xe9/0x170
> [<c02125e6>] take_over_console+0x176/0x350
> [<c01d38da>] fbcon_takeover+0x5a/0x90
> [<c01d846a>] fbcon_fb_registered+0x5a/0x70
> [<c01d8542>] fbcon_event_notify+0x52/0x80
> [<c0121898>] notifier_call_chain+0x18/0x30
> [<c01da667>] register_framebuffer+0xd7/0x150
> [<c0117713>] release_console_sem+0x13/0x90
> [<c017f7c7>] sysfs_new_dirent+0x17/0x60
> [<c017f820>] sysfs_make_dirent+0x10/0x70
> [<c017f59a>] sysfs_add_file+0x3a/0x60
> [<e0c4a698>] radeonfb_pci_register+0x308/0x510 [radeonfb]
> [<c01ce482>] pci_device_probe_static+0x32/0x50
> [<c01ce4c7>] __pci_device_probe+0x27/0x40
> [<c01ce4fb>] pci_device_probe+0x1b/0x40
> [<c021ef31>] driver_probe_device+0x21/0x60
> [<c021f05d>] driver_attach+0x4d/0x80
> [<c021f44d>] bus_add_driver+0x6d/0xa0
> [<c021f948>] driver_register+0x28/0x30
> [<c01ce6c4>] pci_register_driver+0x54/0x70
> [<c012b1a2>] sys_init_module+0x112/0x190
> [<c0102c49>] sysenter_past_esp+0x52/0x79
> Code: 24 60 8b 54 24 58 29 ce 0f be 07 89 f1 d3 f8 21 d0 8b 54 24 4c 8b 4c 24 54 23 0c 82 8b 54 24 64 89 c8 31 d0 89 da 83 c3 04 85 f6 <89> 02 75 06 be 08 00 00 00 47 8b 04 24 48 89 04 24 83 3c 24 ff
> <6>usbcore: registered new driver hiddev
> input: USB HID v1.10 Mouse [Logitech Apple Optical USB Mouse] on usb-0000:00:10.2-1
> usbcore: registered new driver usbhid
> drivers/usb/input/hid-core.c: v2.0:USB HID core driver
modedb can not be __init because fb_find_mode() may get db == NULL.
fb_find_mode() is called from modules.
Signed-off-by: Olaf Hering <[email protected]>
diff -purNx tags linux-2.6.11-rc5.orig/drivers/video/modedb.c linux-2.6.11-rc5/drivers/video/modedb.c
--- linux-2.6.11-rc5.orig/drivers/video/modedb.c 2005-02-24 17:40:24.000000000 +0100
+++ linux-2.6.11-rc5/drivers/video/modedb.c 2005-02-26 01:37:43.138003474 +0100
@@ -37,7 +37,7 @@ const char *global_mode_option;
#define DEFAULT_MODEDB_INDEX 0
-static const __init struct fb_videomode modedb[] = {
+static const struct fb_videomode modedb[] = {
{
/* 640x400 @ 70 Hz, 31.5 kHz hsync */
NULL, 70, 640, 400, 39721, 40, 24, 39, 9, 96, 2,
On Sat, 26 Feb 2005, Olaf Hering wrote:
>
> modedb can not be __init because fb_find_mode() may get db == NULL.
> fb_find_mode() is called from modules.
Ack. Maybe somebody should run the scripts again to check that we don't
reference __init data from non-init functions.
Linus
On Fri, 2005-02-25 at 14:30 +0100, Mws wrote:
> hi,
>
> i also have problems with 2.6.11-rc5 and radeon:
>
> i am using a ATI Radeon X600 PciExpress.
>
> a) now the console framebuffer seems to bee working, thx benjamin :)
> b) when bootup seq ist completed and i want to start X (xorg-x11) with ati-drivers
> x is freezing - not your problem, but the console is not correctly restored :/ the only way
> out is to reset the machine :/
> 2.6.11-rc3 was running fine in this case
Hrm, the binary drivers ? oh well... some users had them freezing vs.
radeonfb before and not now. I don't know what they do and don't have
access to a machine with them (there are no ppc versions) so it will be
difficult to track. I suspect they completely reconfigure the chip and
don't restore it properly tho.
What exactly is happening. Does X launches at all ? When does it
freeze ? On X launch or when exiting it ? Have you tried disabling
dynamic clock tweaking ? (radeonfb.default_dynclk=-1 or 0 on the
cmdline, first one means "don't touch the registers", secoond one means
"disable dynamic clocks").
> i have attached my lspci -vv & lspci -tv output and following a small seq of the dmesg output
> when initializing the radeon fb.
>
> if i can provide/assit you with testing, i am available to do so, also if you need more information
> on my system.
>
> i am subscribed to lkml, but i would like to be included into cc seprately, thx.
>
>
> radeonfb_pci_register BEGIN
> ACPI: PCI interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
> radeonfb (0000:05:00.0): Found 131072k of DDR 128 bits wide videoram
> radeonfb (0000:05:00.0): mapped 16384k videoram
> radeonfb: Found Intel x86 BIOS ROM Image
> radeonfb: Retreived PLL infos from BIOS
> radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=400.00 Mhz, System=300.00 MHz
> radeonfb: PLL min 20000 max 40000
> 1 chips in connector info
> - chip 1 has 2 connectors
> * connector 0 of type 2 (CRT) : 2300
> * connector 1 of type 3 (DVI-I) : 3221
> Starting monitor auto detection...
> radeonfb: I2C (port 1) ... not found
> radeonfb: I2C (port 2) ... not found
> radeonfb: I2C (port 3) ... found CRT display
> radeonfb: I2C (port 4) ... not found
> radeonfb: I2C (port 2) ... not found
> radeonfb: I2C (port 4) ... not found
> radeonfb: I2C (port 3) ... found CRT display
> radeonfb: Monitor 1 type CRT found
> radeonfb: EDID probed
> radeonfb: Monitor 2 type no found
> Display is GTF capable
> hStart = 1344, hEnd = 1504, hTotal = 1728
> vStart = 1025, vEnd = 1028, vTotal = 1072
> h_total_disp = 0x9f00d7 hsync_strt_wid = 0x14054a
> v_total_disp = 0x3ff042f vsync_strt_wid = 0x30400
> pixclock = 6349
> freq = 15750
> freq = 15750, PLL min = 20000, PLL max = 40000
> ref_div = 12, ref_clk = 2700, output_freq = 31500
> ref_div = 12, ref_clk = 2700, output_freq = 31500
> post div = 0x1
> fb_div = 0x8c
> ppll_div_3 = 0x1008c
> Console: switching to colour frame buffer device 160x64
> radeonfb (0000:05:00.0): ATI Radeon [b
> radeonfb_pci_register END
>
--
Benjamin Herrenschmidt <[email protected]>
On Fri, Feb 25, Linus Torvalds wrote:
>
>
> On Sat, 26 Feb 2005, Olaf Hering wrote:
> >
> > modedb can not be __init because fb_find_mode() may get db == NULL.
> > fb_find_mode() is called from modules.
>
> Ack. Maybe somebody should run the scripts again to check that we don't
> reference __init data from non-init functions.
sparse doesnt do that, yet? (I never looked at it.)
> > It seem to detect the flat panel incorrectly, or the EDID data is bogus,
> > maybe that's wrecking something in the new modelist management in
> > fbdev ? It might be causing us to use a bogus mode that itself casues
> > atyfb to crash. Tried forcing a mode ?
>
> cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
> fast_imageblit(237) s daea4000 dst1 fa51a800
> fast_imageblit(269) j 1 fa51a800 0
> Unable to handle kernel paging request at virtual address fa51a800
>
> is bitstart incorrect or is the thing just not (yet) mapped?
It should be all mapped, i suspect the mode set is totally bogus. To
check it, can you enable radeonfb verbose debug ?
> radeonfb: Found Intel x86 BIOS ROM Image
> radeonfb: Retreived PLL infos from BIOS
> radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=133.00 Mhz, System=133.00 MHz
> radeonfb: PLL min 12000 max 35000
> radeonfb: Monitor 1 type DFP found
> radeonfb: EDID probed
> radeonfb: Monitor 2 type no found
> radeonfb: Assuming panel size 8x1
> radeonfb: Can't find mode for panel size, going back to CRT
> cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
> fast_imageblit(237) s daea4000 dst1 fa51a800
> fast_imageblit(269) j 1 fa51a800 0
> Unable to handle kernel paging request at virtual address fa51a800
> printing eip:
> c020f17e
> *pde = 00000000
> Oops: 0002 [#1]
> Modules linked in: ohci1394 ieee1394 radeonfb i2c_algo_bit i2c_core ehci_hcd uhci_hcd capability usbcore
> CPU: 0
> EIP: 0060:[<c020f17e>] Tainted: G U VLI
> EFLAGS: 00010282 (2.6.11-rc5-20050225-default)
> EIP is at cfb_imageblit+0x57e/0x67c
> eax: 00000000 ebx: 00000001 ecx: 00000000 edx: fa51a800
> esi: fa51a804 edi: daea4000 ebp: 00000004 esp: dcae9c14
> ds: 007b es: 007b ss: 0068
> Process modprobe (pid: 2080, threadinfo=dcae8000 task=dc4a7550)
> Stack: c01110ac 00000001 c0321d60 dcae9c20 dcae9c20 c01303a2 00000001 c03c87a8
> 0000000a dae23ca8 c011c783 00000046 00000000 dc202000 00000046 dcae9c64
> c010513d 0000384d dc202290 00000007 c032db20 daea4000 00000000 0000000f
> Call Trace:
> [<c01110ac>] smp_local_timer_interrupt+0xc/0x50
> [<c01303a2>] handle_IRQ_event+0x32/0x70
> [<c011c783>] __do_softirq+0x43/0xa0
> [<c010513d>] do_IRQ+0x3d/0x60
> [<c020d790>] soft_cursor+0x190/0x200
> [<c02043cc>] bit_cursor+0x48c/0x4f0
> [<e0b26c01>] radeonfb_prim_fillrect+0xf1/0x120 [radeonfb]
> [<c012043f>] msleep+0x2f/0x40
> [<c01fff28>] fbcon_cursor+0x1a8/0x280
> [<c023ad08>] hide_cursor+0x18/0x30
> [<c023b014>] redraw_screen+0x174/0x200
> [<c01fed4a>] fbcon_prepare_logo+0x39a/0x3a0
> [<c01ff8a0>] fbcon_init+0x2b0/0x370
> [<c023b1a9>] visual_init+0xe9/0x170
>
--
Benjamin Herrenschmidt <[email protected]>
On Fri, 2005-02-25 at 21:24 +0100, Olaf Hering wrote:
> On Fri, Feb 25, James Simmons wrote:
>
> >
> > > cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
> > > fast_imageblit(237) s daea4000 dst1 fa51a800
> > > fast_imageblit(269) j 1 fa51a800 0
> > > Unable to handle kernel paging request at virtual address fa51a800
> > >
> > > is bitstart incorrect or is the thing just not (yet) mapped?
> >
> > Looks like the screen_base is not mapped to.
>
> rc3 worked ok, rc4 does not. testing the -bk snapshots now.
Oh, it's probably the new radeonfb, I have no doubt about that, but I
think the problems has to do with a bogus mode. Maybe set_par is simply
failing and the fbdev layer still tries to tap the card or something
like that. Please, enable verbose debug, add some printk's around
set_par to check what the mode looks like and what gets ioremap'ed.
Ben.
On Fri, 2005-02-25 at 22:21 +0100, Olaf Hering wrote:
> On Fri, Feb 25, Olaf Hering wrote:
>
> > On Fri, Feb 25, James Simmons wrote:
> >
> > >
> > > > cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
> > > > fast_imageblit(237) s daea4000 dst1 fa51a800
> > > > fast_imageblit(269) j 1 fa51a800 0
> > > > Unable to handle kernel paging request at virtual address fa51a800
> > > >
> > > > is bitstart incorrect or is the thing just not (yet) mapped?
> > >
> > > Looks like the screen_base is not mapped to.
> >
> > rc3 worked ok, rc4 does not. testing the -bk snapshots now.
>
> bk8 works, bk9 breaks, it contains the radeonfb update.
> it works ok if the driver is compiled into the kernel.
Ah, that's a good point. Can you send me the dmesg outputs of in kernel
vs. in module with radeonfb verbose debug enabled ?
Ben.
On Sat, 2005-02-26 at 00:30 +0100, Olaf Hering wrote:
> On Fri, Feb 25, Olaf Hering wrote:
>
> > On Fri, Feb 25, Olaf Hering wrote:
> >
> > > On Fri, Feb 25, James Simmons wrote:
> > >
> > > >
> > > > > cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
> > > > > fast_imageblit(237) s daea4000 dst1 fa51a800
> > > > > fast_imageblit(269) j 1 fa51a800 0
> > > > > Unable to handle kernel paging request at virtual address fa51a800
> > > > >
> > > > > is bitstart incorrect or is the thing just not (yet) mapped?
> > > >
> > > > Looks like the screen_base is not mapped to.
> > >
> > > rc3 worked ok, rc4 does not. testing the -bk snapshots now.
> >
> > bk8 works, bk9 breaks, it contains the radeonfb update.
> > it works ok if the driver is compiled into the kernel.
>
>
> modedb = rinfo->mon1_modedb; passes some shit to fb_find_mode() which
> kills my screen(1) when DPRINTK is enabled. it dies because bitstart
> relies on xres_virtual which is 0xcccccc or whatever.
I think the problem is that you have totally bogus EDID data coming from
DDC. I'm still curious what makes a difference between module and
built-in. Either we try to set a bogus mode, or we just fail setting a
mode at all and fbdev doesn't deal with that properly.
Did you try plugging a different monitor ? Also, do you have output with
a recent X.org (6.8.2 for example) ? Can you send me that log too ?
Ben.
On Sat, 26 Feb 2005, Olaf Hering wrote:
>
> sparse doesnt do that, yet? (I never looked at it.)
No, it doesn't look at the section info. I guess I could do it, but there
_is_ a "make buildcheck" which does it based on perl stuff and the link
information.
And I can do "make buildcheck" myself, but some people have done it before
and know which ones are false positives etc, so I was hoping..
Hint hint, wherever you are..
Linus
Linus Torvalds wrote:
>
> On Sat, 26 Feb 2005, Olaf Hering wrote:
>
>>modedb can not be __init because fb_find_mode() may get db == NULL.
>>fb_find_mode() is called from modules.
>
>
> Ack. Maybe somebody should run the scripts again to check that we don't
> reference __init data from non-init functions.
>
> Linus
>
This patch has already been posted to linux-fbdev on 2005-02-10 by David Vrabel
and made me ask
Is there any reason why this has been originally flagged "__init"?
"vesa_modes" is not "__init". That's why I changed "intelfb" to
use "vesa_modes".
Maybe time has come to decide, if availability of "modedb" outside
of init functions is more important than freeing (unused) kernel memory.
--Axel
On Sat, 2005-02-26 at 01:41 +0100, Olaf Hering wrote:
>
> modedb can not be __init because fb_find_mode() may get db == NULL.
> fb_find_mode() is called from modules.
Ahhh, good catch ! I though that was fixed long ago, looks like I was
wrong.
Ben.
> Signed-off-by: Olaf Hering <[email protected]>
>
> diff -purNx tags linux-2.6.11-rc5.orig/drivers/video/modedb.c linux-2.6.11-rc5/drivers/video/modedb.c
> --- linux-2.6.11-rc5.orig/drivers/video/modedb.c 2005-02-24 17:40:24.000000000 +0100
> +++ linux-2.6.11-rc5/drivers/video/modedb.c 2005-02-26 01:37:43.138003474 +0100
> @@ -37,7 +37,7 @@ const char *global_mode_option;
>
> #define DEFAULT_MODEDB_INDEX 0
>
> -static const __init struct fb_videomode modedb[] = {
> +static const struct fb_videomode modedb[] = {
> {
> /* 640x400 @ 70 Hz, 31.5 kHz hsync */
> NULL, 70, 640, 400, 39721, 40, 24, 39, 9, 96, 2,
--
Benjamin Herrenschmidt <[email protected]>
> This patch has already been posted to linux-fbdev on 2005-02-10 by David Vrabel
> and made me ask
> Is there any reason why this has been originally flagged "__init"?
> "vesa_modes" is not "__init". That's why I changed "intelfb" to
> use "vesa_modes".
>
> Maybe time has come to decide, if availability of "modedb" outside
> of init functions is more important than freeing (unused) kernel memory.
Well, I wonder why we need that mode db at all ... We should probably
use VESA modes and calculate using the standard formula if the user
requests a mode that isn't in the vesa table... Most monitors will
provide additional detailed timings for non-vesa modes they may
support.
Ben.
Lee Revell wrote:
> On Fri, 2005-02-25 at 16:47 -0500, Bill Davidsen wrote:
>
>>- sound: hasn't worked since FC1...
>>
>
>
> The ALSA lists have been deluged with reports like "sound worked in FC1,
> upgraded to FC3, no sound". AFAICT it's just sloppiness on the part of
> the Fedora userspace tools. For example, last I heard
> system-config-soundcard tries to load the emu10k1 module for cards that
> need the (completely different) emu10k1x driver.
The modules look good to me, they are the Intel modules which should
would with ICH4-M.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
Benjamin Herrenschmidt wrote:
> I'm still curious what makes a difference between module and
> built-in.
There seems to be quite some difference between module and
built-in for framebuffer drivers. Quite some time ago I
reported a problem with nVidia framebuffer driver making the
screen go nuts or simply blank (but no lock-up; could still
blind type). I finally discovered that the problem only
happened when the driver was compiled as a module.
--
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)
On Sat, 26 Feb 2005, Benjamin Herrenschmidt wrote:
> On Sat, 2005-02-26 at 01:41 +0100, Olaf Hering wrote:
> > modedb can not be __init because fb_find_mode() may get db == NULL.
> > fb_find_mode() is called from modules.
>
> Ahhh, good catch ! I though that was fixed long ago, looks like I was
> wrong.
Yep, I was surprised by this bug as well...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Feb 23, Linus Torvalds wrote:
> This time it's really supposed to be a quickie, so people who can, please
> check it out, and we'll make the real 2.6.11 asap.
Here is another one, probably not new.
Is riva_get_EDID_i2c a bit too optimistic by not having a $i2cadapter_ok
member in riva_par->riva_i2c_chan? It calls riva_probe_i2c_connector
even if riva_create_i2c_busses fails to register all 3 busses.
Feb 27 00:32:51 vdr kernel: ACPI-0367: *** Warning: Unable to derive IRQ
for device 0000:01:00.0
Feb 27 00:32:51 vdr kernel: ACPI: PCI interrupt 0000:01:00.0[A]: no GSI -
using IRQ 11
Feb 27 00:32:51 vdr kernel: rivafb: nVidia device/chipset 10DE0029
Feb 27 00:32:51 vdr kernel: rivafb: RIVA MTRR set to ON
Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (0) scl=60, sda=1
Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (1) scl=53, sda=0
Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (2) scl=63, sda=1
Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (3) scl=59, sda=1
Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: SCL stuck high!
Feb 27 00:32:51 vdr kernel: rivafb 0000:01:00.0: Failed to register I2C bus
BUS1.
Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (0) scl=30, sda=1
Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (1) scl=23, sda=0
Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (2) scl=31, sda=1
Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (3) scl=59, sda=1
Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: SCL stuck high!
Feb 27 00:32:51 vdr kernel: rivafb 0000:01:00.0: Failed to register I2C bus
BUS2.
Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (0) scl=0, sda=0
Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: BUS3 seems to be busy.
Feb 27 00:32:51 vdr kernel: rivafb 0000:01:00.0: Failed to register I2C bus
BUS3.
Feb 27 00:32:51 vdr kernel: Unable to handle kernel NULL pointer dereference
at virtual address 00000024
Feb 27 00:32:51 vdr kernel: printing eip:
Feb 27 00:32:51 vdr kernel: d09bcafc
Feb 27 00:32:51 vdr kernel: *pde = 00000000
Feb 27 00:32:51 vdr kernel: Oops: 0000 [#1]
Feb 27 00:32:51 vdr kernel: Modules linked in: usbhid evdev joydev sg st
sd_mod sr_mod scsi_mod rivafb i2c_algo_bit vgastate dvb_ttpci dvb_core
saa7146_vv video_buf saa7146 v4l1_compat v4l2_common v
ideodev ves1820 stv0299 tda8083 stv0297 8139too mii sp8870 firmware_class
ves1x93 i2c_piix4 ttpci_eeprom i2c_core intel_agp uhci_hcd pci_hotplug agpgart
usbcore subfs dm_mod ide_cd cdrom ide_floppy
ide_disk reiserfs piix ide_core
Feb 27 00:32:51 vdr kernel: CPU: 0
Feb 27 00:32:51 vdr kernel: EIP: 0060:[<d09bcafc>] Not tainted VLI
Feb 27 00:32:51 vdr kernel: EFLAGS: 00010286 (2.6.11-rc4-bk9-27-default)
Feb 27 00:32:51 vdr kernel: EIP is at i2c_transfer+0xc/0x40 [i2c_core]
Feb 27 00:32:51 vdr kernel: eax: 00000000 ebx: ffffffda ecx: 00000002
edx: cd6f3e18
Feb 27 00:32:51 vdr kernel: esi: cfa35624 edi: cfe40160 ebp: 00000003
esp: cd6f3e04
Feb 27 00:32:51 vdr kernel: ds: 007b es: 007b ss: 0068
Feb 27 00:32:51 vdr kernel: Process modprobe (pid: 2613, threadinfo=cd6f2000
task=cddfd080)
Feb 27 00:32:51 vdr kernel: Stack: cd6f3e18 cfa3561c d0a1ce3f 00000246
003b5219 00000050 00000001 cd6f3e17
Feb 27 00:32:51 vdr kernel: 00010050 00000080 cfe40160 d0a1de98
cd6f3e40 00000000 000001e4 cfa35290
Feb 27 00:32:51 vdr kernel: cfa355f4 d0a1cec7 cfa35290 00000001
00000000 cfa355f4 d0a17de8 00000001
Feb 27 00:32:51 vdr kernel: Call Trace:
Feb 27 00:32:51 vdr kernel: [<d0a1ce3f>] riva_do_probe_i2c_edid+0x7f/0xe0
[rivafb]
Feb 27 00:32:51 vdr kernel: [<d0a1cec7>] riva_probe_i2c_connector+0x27/0xa0
[rivafb]
Feb 27 00:32:51 vdr kernel: [<d0a17de8>] riva_get_EDID_i2c+0x48/0x90 [rivafb]
Feb 27 00:32:51 vdr kernel: [<c010528d>] do_IRQ+0x3d/0x60
Feb 27 00:32:51 vdr kernel: [<c0103cba>] common_interrupt+0x1a/0x20
Feb 27 00:32:51 vdr kernel: [<c0228288>] poke_blanked_console+0x68/0xb0
Feb 27 00:32:51 vdr kernel: [<c02274c5>] vt_console_print+0x295/0x340
Feb 27 00:32:51 vdr kernel: [<c0227230>] vt_console_print+0x0/0x340
Feb 27 00:32:51 vdr kernel: [<c0119f51>] __call_console_drivers+0x41/0x50
Feb 27 00:32:51 vdr kernel: [<c011a028>] call_console_drivers+0x78/0x110
Feb 27 00:32:51 vdr kernel: [<c011a29b>] vprintk+0xeb/0x100
Feb 27 00:32:51 vdr kernel: [<d0a17ec5>] riva_get_EDID+0x5/0x20 [rivafb]
Feb 27 00:32:51 vdr kernel: [<d0a182eb>] rivafb_probe+0x2db/0x510 [rivafb]
Feb 27 00:32:51 vdr kernel: [<c01dab82>] pci_device_probe_static+0x32/0x50
Feb 27 00:32:51 vdr kernel: [<c01dabc7>] __pci_device_probe+0x27/0x40
Feb 27 00:32:51 vdr kernel: [<c01dabfb>] pci_device_probe+0x1b/0x40
Feb 27 00:32:51 vdr kernel: [<c0234531>] driver_probe_device+0x21/0x60
Feb 27 00:32:51 vdr kernel: [<c023465d>] driver_attach+0x4d/0x80
Feb 27 00:32:51 vdr kernel: [<c0234a4d>] bus_add_driver+0x6d/0xa0
Feb 27 00:32:51 vdr kernel: [<c0234f48>] driver_register+0x28/0x30
Feb 27 00:32:51 vdr kernel: [<c01dadc4>] pci_register_driver+0x54/0x70
Feb 27 00:32:51 vdr kernel: [<c012e774>] sys_init_module+0x104/0x180
Feb 27 00:32:51 vdr kernel: [<c0102c49>] sysenter_past_esp+0x52/0x79
Feb 27 00:32:51 vdr kernel: Code: 31 db 8b 50 70 85 d2 74 07 8b 4a 68 85 c9 75
04 89 d8 5b c3 31 d2 ff d1 89 c3 89 d8 5b c3 90 56 53 89 c6 8b 40 0c bb da ff
ff ff <8b> 40 24 85 c0 74 1e ff 4e 1c 0f
88 59 13 00 00 8b 5e 0c 89 f0
On Saturday 26 February 2005 09:13, Benjamin Herrenschmidt wrote:
> On Sat, 2005-02-26 at 01:41 +0100, Olaf Hering wrote:
> > modedb can not be __init because fb_find_mode() may get db == NULL.
> > fb_find_mode() is called from modules.
>
> Ahhh, good catch ! I though that was fixed long ago, looks like I was
> wrong.
The 2.4 fix was for fb_find_mode to always return 640x480 if modular.
There's no fix yet for 2.6 except for the patch which is already in the mm
tree, which is for fb_find_mode() to always fail if driver is compiled as a
module. (patch below).
Both fixes will still crash if fb_find_mode() is called again, so this
function is really designed to be called only once.
As for the other patch that removes the __init from modedb, some of the
developers might disagree.
Olaf,
Can you send me your EDID block? You can use read-edid. Your monitor
may have a fixable EDID and can be a candidate for the broken display
database.
Tony
On Monday 28 February 2005 04:32, Olaf Hering wrote:
> On Wed, Feb 23, Linus Torvalds wrote:
> > This time it's really supposed to be a quickie, so people who can, please
> > check it out, and we'll make the real 2.6.11 asap.
>
> Here is another one, probably not new.
> Is riva_get_EDID_i2c a bit too optimistic by not having a $i2cadapter_ok
> member in riva_par->riva_i2c_chan? It calls riva_probe_i2c_connector
> even if riva_create_i2c_busses fails to register all 3 busses.
>
Thanks,
Can you try this?
Fixed error handling in rivafb-i2c.c if bus registration fails.
Signed-off-by: Antonino Daplas <[email protected]>
---
rivafb-i2c.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff -Nru a/drivers/video/riva/rivafb-i2c.c b/drivers/video/riva/rivafb-i2c.c
--- a/drivers/video/riva/rivafb-i2c.c 2005-01-13 03:57:12 +08:00
+++ b/drivers/video/riva/rivafb-i2c.c 2005-02-28 08:22:06 +08:00
@@ -120,8 +120,12 @@
rc = i2c_bit_add_bus(&chan->adapter);
if (rc == 0)
dev_dbg(&chan->par->pdev->dev, "I2C bus %s registered.\n", name);
- else
- dev_warn(&chan->par->pdev->dev, "Failed to register I2C bus %s.\n", name);
+ else {
+ dev_warn(&chan->par->pdev->dev,
+ "Failed to register I2C bus %s.\n", name);
+ chan->par = NULL;
+ }
+
return rc;
}
@@ -171,6 +175,9 @@
},
};
u8 *buf;
+
+ if (!chan->par)
+ return NULL;
buf = kmalloc(EDID_LENGTH, GFP_KERNEL);
if (!buf) {
hi benjamin
now i had some spare time to do some investigation
booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1
brings up a framebuffer console. everything is fine.
starting xorg-x11 with Ati binary only drivers just brings up a black screen
without a mouse cursor and freezes the hole machine. even network ect.
is no more reachable from outside the machine. worst thing out of that
a tail on the log files (on another machine) does immediately stop - also no
output is written to syslog :/
next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1
starting xorg-x11 with Xorg Radeon driver.
a grey screen comes up - mouse cursor is visible and also able to move for
5 - 8 seconds after screen display - then freezes the whole machine again.
regards
marcel
On Saturday 26 February 2005 01:50, Benjamin Herrenschmidt wrote:
> On Fri, 2005-02-25 at 14:30 +0100, Mws wrote:
> > hi,
> >
> > i also have problems with 2.6.11-rc5 and radeon:
> >
> > i am using a ATI Radeon X600 PciExpress.
> >
> > a) now the console framebuffer seems to bee working, thx benjamin :)
> > b) when bootup seq ist completed and i want to start X (xorg-x11) with ati-drivers
> > x is freezing - not your problem, but the console is not correctly restored :/ the only way
> > out is to reset the machine :/
> > 2.6.11-rc3 was running fine in this case
>
> Hrm, the binary drivers ? oh well... some users had them freezing vs.
> radeonfb before and not now. I don't know what they do and don't have
> access to a machine with them (there are no ppc versions) so it will be
> difficult to track. I suspect they completely reconfigure the chip and
> don't restore it properly tho.
> What exactly is happening. Does X launches at all ? When does it
> freeze ? On X launch or when exiting it ? Have you tried disabling
> dynamic clock tweaking ? (radeonfb.default_dynclk=-1 or 0 on the
> cmdline, first one means "don't touch the registers", secoond one means
> "disable dynamic clocks").
On Mon, Feb 28, Antonino A. Daplas wrote:
> On Monday 28 February 2005 04:32, Olaf Hering wrote:
> > On Wed, Feb 23, Linus Torvalds wrote:
> > > This time it's really supposed to be a quickie, so people who can, please
> > > check it out, and we'll make the real 2.6.11 asap.
> >
> > Here is another one, probably not new.
> > Is riva_get_EDID_i2c a bit too optimistic by not having a $i2cadapter_ok
> > member in riva_par->riva_i2c_chan? It calls riva_probe_i2c_connector
> > even if riva_create_i2c_busses fails to register all 3 busses.
> >
>
> Thanks,
>
> Can you try this?
>
> Fixed error handling in rivafb-i2c.c if bus registration fails.
I havent heard back from the reporter, yet.
Mws wrote:
>hi benjamin
>
>now i had some spare time to do some investigation
>
>booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1
>brings up a framebuffer console. everything is fine.
>starting xorg-x11 with Ati binary only drivers just brings up a black screen
>without a mouse cursor and freezes the hole machine. even network ect.
>is no more reachable from outside the machine. worst thing out of that
>a tail on the log files (on another machine) does immediately stop - also no
>output is written to syslog :/
>
>next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1
>starting xorg-x11 with Xorg Radeon driver.
>a grey screen comes up - mouse cursor is visible and also able to move for
>5 - 8 seconds after screen display - then freezes the whole machine again.
>
>
Did you try without dri? (Comment out dri in the X config file)
I use a radeon 7000 VE at work, where X will hang after a few
seconds if dri is enabled in X. Disable dri, and it is
rock solid. xfree or x.org makes no difference here.
Helge Hafting
On Tuesday 01 March 2005 15:36, Helge Hafting wrote:
> Mws wrote:
>
> >hi benjamin
> >
> >now i had some spare time to do some investigation
> >
> >booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1
> >brings up a framebuffer console. everything is fine.
> >starting xorg-x11 with Ati binary only drivers just brings up a black screen
> >without a mouse cursor and freezes the hole machine. even network ect.
> >is no more reachable from outside the machine. worst thing out of that
> >a tail on the log files (on another machine) does immediately stop - also no
> >output is written to syslog :/
> >
> >next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1
> >starting xorg-x11 with Xorg Radeon driver.
> >a grey screen comes up - mouse cursor is visible and also able to move for
> >5 - 8 seconds after screen display - then freezes the whole machine again.
> >
> >
> Did you try without dri? (Comment out dri in the X config file)
> I use a radeon 7000 VE at work, where X will hang after a few
> seconds if dri is enabled in X. Disable dri, and it is
> rock solid. xfree or x.org makes no difference here.
>
> Helge Hafting
hi,
i had dri disabled already :/
regards
marcel
On Mon, Feb 28, Antonino A. Daplas wrote:
> On Monday 28 February 2005 04:32, Olaf Hering wrote:
> > On Wed, Feb 23, Linus Torvalds wrote:
> > > This time it's really supposed to be a quickie, so people who can, please
> > > check it out, and we'll make the real 2.6.11 asap.
> >
> > Here is another one, probably not new.
> > Is riva_get_EDID_i2c a bit too optimistic by not having a $i2cadapter_ok
> > member in riva_par->riva_i2c_chan? It calls riva_probe_i2c_connector
> > even if riva_create_i2c_busses fails to register all 3 busses.
Side note:
<[email protected]>: connect to
lists.surfsouth.com[216.128.200.12]: Connection timed out
Is this one supposed to work? perhaps the MAINTAINERS entry needs an
update.
On Tue, 2005-03-01 at 12:36 +0100, Mws wrote:
> hi benjamin
>
> now i had some spare time to do some investigation
>
> booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1
> brings up a framebuffer console. everything is fine.
> starting xorg-x11 with Ati binary only drivers just brings up a black screen
> without a mouse cursor and freezes the hole machine. even network ect.
> is no more reachable from outside the machine. worst thing out of that
> a tail on the log files (on another machine) does immediately stop - also no
> output is written to syslog :/
>
> next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1
> starting xorg-x11 with Xorg Radeon driver.
> a grey screen comes up - mouse cursor is visible and also able to move for
> 5 - 8 seconds after screen display - then freezes the whole machine again.
Ok, so it's not dynamic clocks. At this point, i have no idea what's
going on. I don't yet have any access to PCI Express hardware. You
should report this to X.org list where others can try to help me track
this down.
Ben.
On Tuesday 01 March 2005 22:38, Benjamin Herrenschmidt wrote:
> On Tue, 2005-03-01 at 12:36 +0100, Mws wrote:
> > hi benjamin
> >
> > now i had some spare time to do some investigation
> >
> > booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1
> > brings up a framebuffer console. everything is fine.
> > starting xorg-x11 with Ati binary only drivers just brings up a black screen
> > without a mouse cursor and freezes the hole machine. even network ect.
> > is no more reachable from outside the machine. worst thing out of that
> > a tail on the log files (on another machine) does immediately stop - also no
> > output is written to syslog :/
> >
> > next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1
> > starting xorg-x11 with Xorg Radeon driver.
> > a grey screen comes up - mouse cursor is visible and also able to move for
> > 5 - 8 seconds after screen display - then freezes the whole machine again.
>
> Ok, so it's not dynamic clocks. At this point, i have no idea what's
> going on. I don't yet have any access to PCI Express hardware. You
> should report this to X.org list where others can try to help me track
> this down.
>
> Ben.
it's possible to do so, but i also will try to find out whats going on.
i don't know if i will have success.
regards
marcel