Re: Linux-2.6.13-rc7
On Fri, Aug 26, 2005 at 09:33:29PM -0700, Deepak Saxena wrote: > On Aug 25 2005, at 16:04, Erik Mouw was caught saying: > > On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: > > > I really wanted to release a 2.6.13, but there's been enough changes > > > while we've been waiting for other issues to resolve that I think it's > > > best to do a -rc7 first. > > > > There's something strange going on with either ACPI or cpufreq. When > > Is there ever anything not strange going on with ACPI. :p Heh :) It gets even stranger: I had to boot to windows to be able to backup my phone. After that, I couldn't recreate the 2.6/3.6 GHz CPU problem anymore. Your explanation is as good as mine... Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Fri, Aug 26, 2005 at 09:33:29PM -0700, Deepak Saxena wrote: On Aug 25 2005, at 16:04, Erik Mouw was caught saying: On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: I really wanted to release a 2.6.13, but there's been enough changes while we've been waiting for other issues to resolve that I think it's best to do a -rc7 first. There's something strange going on with either ACPI or cpufreq. When Is there ever anything not strange going on with ACPI. :p Heh :) It gets even stranger: I had to boot to windows to be able to backup my phone. After that, I couldn't recreate the 2.6/3.6 GHz CPU problem anymore. Your explanation is as good as mine... Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
I hate responding to myself but it's necessary: >RC7-GIT7 barfed on me after some 20 hours: complete serial console message before it reset is on: http://newsgate.newsserver.nl/kernel/ as is config-file. Hardware: AMD64 running pure-64 debian ony tyan motherboard with opteron 250 cpu. Danny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
>I Wrote:
>After 53 hours and 31 minutes it crashed.
>dth pts/1zaphod.dth.net Wed Aug 24 09:54 - crash (2+05:31)
>reboot system boot 2.6.13-rc7 Wed Aug 24 09:51 (2+05:41)
>
>Prior to this kernel it had been running 2.6.12-mm1 without problems:
>reboot system boot 2.6.12-mm1 Sun Aug 14 12:13 (9+21:36)
>
>I will now compile & run rc7-git1.
RC7-GIT7 barfed on me after some 20 hours:
root ttyS0 Fri Aug 26 16:32 - crash (20:44)
reboot system boot 2.6.13-rc7-git1 Fri Aug 26 16:32 (20:59)
I managed to get some information from the serial console:
scsi0: SCBPTR == 0x55, SCB_NEXT == 0xff80, SCB_NEXT2 == 0xff6e
CDB 0 0 0 0 0 0
STACK: 0x10c 0x0 0x0 0x0 0x0 0x0 0x0 0x0
< Dump Card State Ends >>
DevQ(0:0:0): 0 waiting
DevQ(0:1:0): NMI Watchdog detected LOCKUP on CPU0CPU 0
Modules linked in: rawfs rtc evdev hw_random i2c_amd8111 tg3 e100 mii w83627hf
eeprom lm85 i2c_sensor i2c_isa i2c_amd756 i2c_core psmouse
Pid: 168, comm: scsi_eh_0 Not tainted 2.6.13-rc7-git1
RIP: 0010:[] {serial_in+105}
RSP: 0018:81007fc17b80 EFLAGS: 0002
RAX: RBX: RCX:
RDX: 03fd RSI: 0005 RDI: 80473a40
RBP: 2705 R08: 0020 R09: 7930
R10: 0034 R11: 000a R12: 80473a40
R13: 8045f6fe R14: 000d R15: 000d
FS: 2b3cbe90() GS:80485800() knlGS:556ada40
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 00515970 CR3: 7dc27000 CR4: 06e0
Process scsi_eh_0 (pid: 168, threadinfo 81007fc16000, task 8100033607c0)
Stack: 8026682d 00050002 803ebc60 7931
000d 0096 0010 0046
8012ed9c 793e
Call Trace:{serial8250_console_write+413}
{__call_console_drivers+76}
{release_console_sem+339}
{vprintk+601}
{vprintk+601} {printk+78}
{thread_return+0} {printk+78}
{ahd_print_register+261}
{ahd_platform_dump_card_state+100}
{ahd_dump_card_state+8973}
{ahd_linux_abort+624}
{ahd_linux_sem_timeout+0}
{scsi_error_handler+1324}
{child_rip+8} {scsi_error_handler+0}
{child_rip+0}
Code: 0f b6 c0 c3 66 66 90 41 57 49 89 f7 41 56 41 55 41 bd 00 01
console shuts up ...
<0>Kernel panic - not syncing: Aiee, killing interrupt handler!
I don't know if this is enough information for the developers to go on.
For me it's back to 2.6.12-mm1 *snif*
Danny
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
I Wrote:
After 53 hours and 31 minutes it crashed.
dth pts/1zaphod.dth.net Wed Aug 24 09:54 - crash (2+05:31)
reboot system boot 2.6.13-rc7 Wed Aug 24 09:51 (2+05:41)
Prior to this kernel it had been running 2.6.12-mm1 without problems:
reboot system boot 2.6.12-mm1 Sun Aug 14 12:13 (9+21:36)
I will now compile run rc7-git1.
RC7-GIT7 barfed on me after some 20 hours:
root ttyS0 Fri Aug 26 16:32 - crash (20:44)
reboot system boot 2.6.13-rc7-git1 Fri Aug 26 16:32 (20:59)
I managed to get some information from the serial console:
scsi0: SCBPTR == 0x55, SCB_NEXT == 0xff80, SCB_NEXT2 == 0xff6e
CDB 0 0 0 0 0 0
STACK: 0x10c 0x0 0x0 0x0 0x0 0x0 0x0 0x0
Dump Card State Ends
DevQ(0:0:0): 0 waiting
DevQ(0:1:0): NMI Watchdog detected LOCKUP on CPU0CPU 0
Modules linked in: rawfs rtc evdev hw_random i2c_amd8111 tg3 e100 mii w83627hf
eeprom lm85 i2c_sensor i2c_isa i2c_amd756 i2c_core psmouse
Pid: 168, comm: scsi_eh_0 Not tainted 2.6.13-rc7-git1
RIP: 0010:[802644f9] 802644f9{serial_in+105}
RSP: 0018:81007fc17b80 EFLAGS: 0002
RAX: RBX: RCX:
RDX: 03fd RSI: 0005 RDI: 80473a40
RBP: 2705 R08: 0020 R09: 7930
R10: 0034 R11: 000a R12: 80473a40
R13: 8045f6fe R14: 000d R15: 000d
FS: 2b3cbe90() GS:80485800() knlGS:556ada40
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 00515970 CR3: 7dc27000 CR4: 06e0
Process scsi_eh_0 (pid: 168, threadinfo 81007fc16000, task 8100033607c0)
Stack: 8026682d 00050002 803ebc60 7931
000d 0096 0010 0046
8012ed9c 793e
Call Trace:8026682d{serial8250_console_write+413}
8012ed9c{__call_console_drivers+76}
8012f053{release_console_sem+339}
8012fbc9{vprintk+601}
8012fbc9{vprintk+601} 8012fc3e{printk+78}
80325a40{thread_return+0} 8012fc3e{printk+78}
8028c235{ahd_print_register+261}
802abc34{ahd_platform_dump_card_state+100}
80296b0d{ahd_dump_card_state+8973}
802ad320{ahd_linux_abort+624}
802aa590{ahd_linux_sem_timeout+0}
80284f5c{scsi_error_handler+1324}
8010e396{child_rip+8} 80284a30{scsi_error_handler+0}
8010e38e{child_rip+0}
Code: 0f b6 c0 c3 66 66 90 41 57 49 89 f7 41 56 41 55 41 bd 00 01
console shuts up ...
0Kernel panic - not syncing: Aiee, killing interrupt handler!
I don't know if this is enough information for the developers to go on.
For me it's back to 2.6.12-mm1 *snif*
Danny
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
I hate responding to myself but it's necessary: RC7-GIT7 barfed on me after some 20 hours: complete serial console message before it reset is on: http://newsgate.newsserver.nl/kernel/ as is config-file. Hardware: AMD64 running pure-64 debian ony tyan motherboard with opteron 250 cpu. Danny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Aug 25 2005, at 16:04, Erik Mouw was caught saying: > On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: > > I really wanted to release a 2.6.13, but there's been enough changes > > while we've been waiting for other issues to resolve that I think it's > > best to do a -rc7 first. > > There's something strange going on with either ACPI or cpufreq. When Is there ever anything not strange going on with ACPI. :p /me goes back to beer. ~Deepak -- Deepak Saxena - [EMAIL PROTECTED] - http://www.plexity.net Even a stopped clock gives the right time twice a day. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Richard Henderson wrote:
> Because I use "extern inline" in the proper way. That is, I have both
> inline and out-of-line versions of some routines.
Is there any reason not to just make the out-of-line version explicit?
i.e.:
/* in some .h file: */
static /*(always!)*/inline int my_func(void)
{
return FOO;
}
extern int OOL_my_func(void);
/* in some .c file: */
int OOL_my_func(void)
{
return my_func();
}
It's a little ugly but there really aren't that many cases of this, right?
Or is this just the principal of the thing? :-)
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Hello, It crashes for me right off the bat: Here is the kernel output: --- Filesystem type is ext2fs, partition type 0x83 kernel /boot/vmlinuz-2.6.13-rc7-git1 root=/dev/hda3 ro console=ttyS0,115200n8 CONSOLE=/dev/ttyS0 [Linux-bzImage, setup=0x1200, size=0x1fe4fa] savedefault boot Linux version 2.6.13-rc7-git1 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2)) #1 SMP Fri Aug 26 15:18:21 EDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 2fff (usable) BIOS-e820: 2fff - 2fff3000 (ACPI NVS) BIOS-e820: 2fff3000 - 3000 (ACPI data) BIOS-e820: fec0 - 0001 (reserved) 767MB LOWMEM available. found SMP MP-table at 000f5fd0 DMI 2.2 present. ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 17 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 6:8 APIC version 17 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 dfl dfl) Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 3000:cec0) Built 1 zonelists Kernel command line: root=/dev/hda3 ro console=ttyS0,115200n8 CONSOLE=/dev/ttyS0 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 868.668 MHz processor. Using tsc 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: 774032k/786368k available (2926k kernel code, 11824k reserved, 1174k data, 220k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 1739.92 BogoMIPS (lpj=8699649) Mount-cache hash table entries: 512 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel Pentium III (Coppermine) stepping 0a Booting processor 1/1 eip 2000 Initializing CPU#1 Calibrating delay using timer specific routine.. 1737.36 BogoMIPS (lpj=8686805) CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: Intel Pentium III (Coppermine) stepping 0a Total of 2 processors activated (3477.29 BogoMIPS). ENABLING IO-APIC IRQs .TIMER: vector=0x31 pin1=2 pin2=-1 checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfb2c0, last bus=1 PCI: Using configuration type 1 mtrr: your CPUs had inconsistent variable MTRR settings mtrr: probably your BIOS does not setup all CPUs. mtrr: corrected configuration. ACPI: Subsystem revision 20050408 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 *7 10 11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 10 devices SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report PCI: Bridge: :00:01.0 IO window: a000-afff MEM window: d000-d3ff PREFETCH window: d400-d5ff Machine check exception polling timer started. audit: initializing netlink socket (disabled) audit(1125070419.160:1): initialized Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). Initializing Cryptographic API PCI: Enabling Via external APIC routing ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] ACPI: Sleep Button (CM) [SLPB] ACPI: CPU0 (power states: C1[C1]) ACPI: CPU1 (power states: C1[C1]) lp: driver loaded but no devices found Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA Apollo Pro 133 chipset agpgart: AGP aperture is 256M @ 0xc000 [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt :01:00.0[A] -> GSI 16
Re: Linux-2.6.13-rc7
Danny ter Haar <[EMAIL PROTECTED]> wrote: >Of course it will probably reboot just after sending this message. Me and my big mouth... If there is a god he is making fun of me right now ;-) After 53 hours and 31 minutes it crashed. dth pts/1zaphod.dth.net Wed Aug 24 09:54 - crash (2+05:31) reboot system boot 2.6.13-rc7 Wed Aug 24 09:51 (2+05:41) Prior to this kernel it had been running 2.6.12-mm1 without problems: reboot system boot 2.6.12-mm1 Sun Aug 14 12:13 (9+21:36) I will now compile & run rc7-git1. This machine has serial console but only for bootpurpose (no logging possible) Wil try and setup some telnet capture service to try and fetch error. Danny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Linus Torvalds <[EMAIL PROTECTED]> wrote: > I really wanted to release a 2.6.13, but there's been enough changes >while we've been waiting for other issues to resolve that I think it's >best to do a -rc7 first. > >Most of the -rc7 changes are pretty trivial, either one-liners or >affecting some particular specific driver or unusual configuration. The >shortlog (appended) should give a pretty good idea of what's up. > > Linus OK, i tried rc7 on my newsgateway and so far it keeps running after 50+ hours of 200megabit in & 200 megabitoutgoing network traffic and sufficient storage to the scsi system. Of course it will probably reboot just after sending this message. If it stays up after 5 days of pounding it will get _my_ stamp of aproval ;-) -- Linux 2.6.13-rc7 ([EMAIL PROTECTED]) (gcc [can't parse]) #??? 1CPU [newsgate.(none)] Memory: TotalUsedFree Shared Buffers Mem: 2058040 2041552 16488 0 616 Swap:0 0 0 Bootup: Wed Aug 24 09:50:30 2005Load average: 3.39 3.25 3.16 2/80 12244 user : 5:06:34.95 10.0% page in :0 nice : 0:42:50.54 1.4% page out:0 system: 16:22:48.44 32.2% swap in :0 idle : 0:25:08.22 0.8% swap out:0 uptime: 2d 2:53:38.68 context :592311164 irq 0: 45792855 timer irq 12: 3 irq 1: 8 i8042 irq 24: 56420796 aic79xx irq 2: 0 cascade [4] irq 25: 479838182 aic79xx, eth3 irq 4: 369 serialirq 28:1007452070 acenic irq 8: 0 rtc -- Danny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Linus Torvalds [EMAIL PROTECTED] wrote: I really wanted to release a 2.6.13, but there's been enough changes while we've been waiting for other issues to resolve that I think it's best to do a -rc7 first. Most of the -rc7 changes are pretty trivial, either one-liners or affecting some particular specific driver or unusual configuration. The shortlog (appended) should give a pretty good idea of what's up. Linus OK, i tried rc7 on my newsgateway and so far it keeps running after 50+ hours of 200megabit in 200 megabitoutgoing network traffic and sufficient storage to the scsi system. Of course it will probably reboot just after sending this message. If it stays up after 5 days of pounding it will get _my_ stamp of aproval ;-) -- Linux 2.6.13-rc7 ([EMAIL PROTECTED]) (gcc [can't parse]) #??? 1CPU [newsgate.(none)] Memory: TotalUsedFree Shared Buffers Mem: 2058040 2041552 16488 0 616 Swap:0 0 0 Bootup: Wed Aug 24 09:50:30 2005Load average: 3.39 3.25 3.16 2/80 12244 user : 5:06:34.95 10.0% page in :0 nice : 0:42:50.54 1.4% page out:0 system: 16:22:48.44 32.2% swap in :0 idle : 0:25:08.22 0.8% swap out:0 uptime: 2d 2:53:38.68 context :592311164 irq 0: 45792855 timer irq 12: 3 irq 1: 8 i8042 irq 24: 56420796 aic79xx irq 2: 0 cascade [4] irq 25: 479838182 aic79xx, eth3 irq 4: 369 serialirq 28:1007452070 acenic irq 8: 0 rtc -- Danny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Danny ter Haar [EMAIL PROTECTED] wrote: Of course it will probably reboot just after sending this message. Me and my big mouth... If there is a god he is making fun of me right now ;-) After 53 hours and 31 minutes it crashed. dth pts/1zaphod.dth.net Wed Aug 24 09:54 - crash (2+05:31) reboot system boot 2.6.13-rc7 Wed Aug 24 09:51 (2+05:41) Prior to this kernel it had been running 2.6.12-mm1 without problems: reboot system boot 2.6.12-mm1 Sun Aug 14 12:13 (9+21:36) I will now compile run rc7-git1. This machine has serial console but only for bootpurpose (no logging possible) Wil try and setup some telnet capture service to try and fetch error. Danny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Hello, It crashes for me right off the bat: Here is the kernel output: --- Filesystem type is ext2fs, partition type 0x83 kernel /boot/vmlinuz-2.6.13-rc7-git1 root=/dev/hda3 ro console=ttyS0,115200n8 CONSOLE=/dev/ttyS0 [Linux-bzImage, setup=0x1200, size=0x1fe4fa] savedefault boot Linux version 2.6.13-rc7-git1 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2)) #1 SMP Fri Aug 26 15:18:21 EDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 2fff (usable) BIOS-e820: 2fff - 2fff3000 (ACPI NVS) BIOS-e820: 2fff3000 - 3000 (ACPI data) BIOS-e820: fec0 - 0001 (reserved) 767MB LOWMEM available. found SMP MP-table at 000f5fd0 DMI 2.2 present. ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 17 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 6:8 APIC version 17 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 dfl dfl) Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 3000:cec0) Built 1 zonelists Kernel command line: root=/dev/hda3 ro console=ttyS0,115200n8 CONSOLE=/dev/ttyS0 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 868.668 MHz processor. Using tsc 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: 774032k/786368k available (2926k kernel code, 11824k reserved, 1174k data, 220k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 1739.92 BogoMIPS (lpj=8699649) Mount-cache hash table entries: 512 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel Pentium III (Coppermine) stepping 0a Booting processor 1/1 eip 2000 Initializing CPU#1 Calibrating delay using timer specific routine.. 1737.36 BogoMIPS (lpj=8686805) CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: Intel Pentium III (Coppermine) stepping 0a Total of 2 processors activated (3477.29 BogoMIPS). ENABLING IO-APIC IRQs .TIMER: vector=0x31 pin1=2 pin2=-1 checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfb2c0, last bus=1 PCI: Using configuration type 1 mtrr: your CPUs had inconsistent variable MTRR settings mtrr: probably your BIOS does not setup all CPUs. mtrr: corrected configuration. ACPI: Subsystem revision 20050408 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 *7 10 11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 10 devices SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try pci=routeirq. If it helps, post a report PCI: Bridge: :00:01.0 IO window: a000-afff MEM window: d000-d3ff PREFETCH window: d400-d5ff Machine check exception polling timer started. audit: initializing netlink socket (disabled) audit(1125070419.160:1): initialized Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). Initializing Cryptographic API PCI: Enabling Via external APIC routing ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] ACPI: Sleep Button (CM) [SLPB] ACPI: CPU0 (power states: C1[C1]) ACPI: CPU1 (power states: C1[C1]) lp: driver loaded but no devices found Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA Apollo Pro 133 chipset agpgart: AGP aperture is 256M @ 0xc000 [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt :01:00.0[A] - GSI 16
Re: Linux-2.6.13-rc7
Richard Henderson wrote:
Because I use extern inline in the proper way. That is, I have both
inline and out-of-line versions of some routines.
Is there any reason not to just make the out-of-line version explicit?
i.e.:
/* in some .h file: */
static /*(always!)*/inline int my_func(void)
{
return FOO;
}
extern int OOL_my_func(void);
/* in some .c file: */
int OOL_my_func(void)
{
return my_func();
}
It's a little ugly but there really aren't that many cases of this, right?
Or is this just the principal of the thing? :-)
-Mitch
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Aug 25 2005, at 16:04, Erik Mouw was caught saying: On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: I really wanted to release a 2.6.13, but there's been enough changes while we've been waiting for other issues to resolve that I think it's best to do a -rc7 first. There's something strange going on with either ACPI or cpufreq. When Is there ever anything not strange going on with ACPI. :p /me goes back to beer. ~Deepak -- Deepak Saxena - [EMAIL PROTECTED] - http://www.plexity.net Even a stopped clock gives the right time twice a day. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Sorry. Here's the start of the thread. Tony On Tue, 23 Aug 2005 22:08:13 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > Antonino A. Daplas: > intelfb/fbdev: Save info->flags in a local variable > Sylvain Meyer: > intelfb: Do not ioremap entire graphics aperture One of these changes broke intelfb. The same .config from 2.6.13-rc6 does no longer work for -rc7. After booting the screen stays black, but i can type blindly. I can also start X. dmesg does not show anything unusual. any ideas? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, Aug 25, 2005 at 03:16:49PM -0700, Richard Henderson wrote:
> On Thu, Aug 25, 2005 at 08:07:55PM +0100, Al Viro wrote:
> > IMO that's a question to rth: why do we really need to block always_inline
> > on alpha?
>
> Because I use "extern inline" in the proper way. That is, I have both
> inline and out-of-line versions of some routines. These routines have
> their address taken to be put into the alpha_machine_vector structures,
> so we're guaranteed that they'll be out-of-line at least once.
>
> But if you define inline to always_inline, the compiler complains when
> its forced to fall back to the out-of-line copy. And rightly so -- the
> feature was INVENTED for using compiler intrinsics that would in fact
> not produce valid assembly unless certain parameters are constants.
>
> I've complained about this before. You always-inline savages have
> obsconded with ALL THREE inline keywords -- "inline", "__inline" and
> "__inline__" -- so there is in fact no way to accomplish what I want.
>
> So in a fit of pique I've locally undone not just one, but all of the
> always-inline crap.
>
> All that said, something's wrong if we couldn't generate an out-of-line
> copy of kmalloc. The entire block protected by __builtin_constant_p
> should have been eliminated. File a gcc bugzilla report.
It is eliminated. As the result, the compile-time checks disappear.
In this case it's more or less harmless - we miss some bugs that could
be caught at compile time, but that's it. In case of e.g. xchg() (same
technics of calling undefined function in the code that gets eliminated
if everything's right) it gave genuine bugs - gcc decided to create an
uninlined copy and to hell it went:
static inline unsigned long
__xchg(volatile void *ptr, unsigned long x, int size)
{
switch (size) {
case 1:
return __xchg_u8(ptr, x);
case 2:
return __xchg_u16(ptr, x);
case 4:
return __xchg_u32(ptr, x);
case 8:
return __xchg_u64(ptr, x);
}
__xchg_called_with_bad_pointer();
return x;
}
#define xchg(ptr,x) \
({ \
__typeof__(*(ptr)) _x_ = (x); \
(__typeof__(*(ptr))) __xchg((ptr), (unsigned long)_x_, sizeof(*(ptr))); \
})
blows to hell, since we have no way to tell gcc that it should _never_
be done non-inlined. Well, no way short of making __xchg a macro...
So what do you propose to use for that class of compile-time checks?
#define whenever they are used?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, Aug 25, 2005 at 08:07:55PM +0100, Al Viro wrote: > IMO that's a question to rth: why do we really need to block always_inline > on alpha? Because I use "extern inline" in the proper way. That is, I have both inline and out-of-line versions of some routines. These routines have their address taken to be put into the alpha_machine_vector structures, so we're guaranteed that they'll be out-of-line at least once. But if you define inline to always_inline, the compiler complains when its forced to fall back to the out-of-line copy. And rightly so -- the feature was INVENTED for using compiler intrinsics that would in fact not produce valid assembly unless certain parameters are constants. I've complained about this before. You always-inline savages have obsconded with ALL THREE inline keywords -- "inline", "__inline" and "__inline__" -- so there is in fact no way to accomplish what I want. So in a fit of pique I've locally undone not just one, but all of the always-inline crap. All that said, something's wrong if we couldn't generate an out-of-line copy of kmalloc. The entire block protected by __builtin_constant_p should have been eliminated. File a gcc bugzilla report. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, Aug 25, 2005 at 11:27:32AM +0400, Alexey Dobriyan wrote:
> Mine is alpha-unknown-linux-gnu-gcc (GCC) 3.4.4 (Gentoo 3.4.4)
>
> > Which place triggers it in your build?
>
> net/ipv4/route.c:3152, call to rt_hash_lock_init().
>
> >From preprocessed source (reformatted):
> ---
> typedef struct {
> volatile unsigned int lock;
>
> int on_cpu;
> int line_no;
> void *previous;
> struct task_struct * task;
> const char *base_file;
> } spinlock_t;
>
> static inline void *kmalloc(size_t size, unsigned int flags)
Oh, lovely...
a) gcc4 on alpha refuses to make that inline
b) bug is real, indeed - spinlock debugging + >32 CPU => panic in ip_rt_init()
IMO that's a question to rth: why do we really need to block always_inline
on alpha?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Sorry but could you re-explain me the problem. Tony, you've only
CC'ed me the end of the story.
Just a correction the options are video=intelfb:accel=0,hwcursor=0
with = and not :
Regards
Sylvain
Sebastian Kaergel a écrit:
On Fri, 26 Aug 2005 00:23:40 +0800
"Antonino A. Daplas" <[EMAIL PROTECTED]> wrote:
Sebastian Kaergel wrote:
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
Probably this one. If vram is less than stolen size, intelfb
will only ioremap the framebuffer memory, excluding the
ringbuffer and the cursor memory.
Try booting with video=intelfb:accel:0,nohwcursor:0. If you get
a display, try this patch.
CC'ed Sylvain.
Signed-off-by: Antonino Daplas <[EMAIL PROTECTED]>
---
Hi,
thanks for your quick reply, but it did not work. the screen remains
black when booting with video=intelfb:accel:0,{,no}hwcursor:0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Sebastian Kaergel wrote:
On Fri, 26 Aug 2005 00:23:40 +0800
"Antonino A. Daplas" <[EMAIL PROTECTED]> wrote:
Sebastian Kaergel wrote:
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
Probably this one. If vram is less than stolen size, intelfb
will only ioremap the framebuffer memory, excluding the
ringbuffer and the cursor memory.
Try booting with video=intelfb:accel:0,nohwcursor:0. If you get
a display, try this patch.
CC'ed Sylvain.
Signed-off-by: Antonino Daplas <[EMAIL PROTECTED]>
---
Hi,
thanks for your quick reply, but it did not work. the screen remains
black when booting with video=intelfb:accel:0,{,no}hwcursor:0
Can you try the patch anyway?
If the patch does not fix your problem, can you revert the patches and
see which is the culprit. I'm attaching those 2 patches.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
drivers/video/intelfb/intelfbdrv.c: needs update
Index: drivers/video/intelfb/intelfbdrv.c
===
--- 0582536f492dc10e4849053d19fec93ca72e9bfe/drivers/video/intelfb/intelfbdrv.c
(mode:100644)
+++ uncommitted/drivers/video/intelfb/intelfbdrv.c (mode:100644)
@@ -579,23 +579,6 @@
return -ENODEV;
}
- /* Map the fb and MMIO regions */
- dinfo->aperture.virtual = (u8 __iomem *)ioremap_nocache
- (dinfo->aperture.physical, dinfo->aperture.size);
- if (!dinfo->aperture.virtual) {
- ERR_MSG("Cannot remap FB region.\n");
- cleanup(dinfo);
- return -ENODEV;
- }
- dinfo->mmio_base =
- (u8 __iomem *)ioremap_nocache(dinfo->mmio_base_phys,
- INTEL_REG_SIZE);
- if (!dinfo->mmio_base) {
- ERR_MSG("Cannot remap MMIO region.\n");
- cleanup(dinfo);
- return -ENODEV;
- }
-
/* Get the chipset info. */
dinfo->pci_chipset = pdev->device;
@@ -679,6 +662,26 @@
}
/* Allocate memories (which aren't stolen) */
+ /* Map the fb and MMIO regions */
+ /* ioremap only up to the end of used aperture */
+ dinfo->aperture.virtual = (u8 __iomem *)ioremap_nocache
+ (dinfo->aperture.physical, ((offset + dinfo->fb.offset) << 12)
++ dinfo->fb.size);
+ if (!dinfo->aperture.virtual) {
+ ERR_MSG("Cannot remap FB region.\n");
+ cleanup(dinfo);
+ return -ENODEV;
+ }
+
+ dinfo->mmio_base =
+ (u8 __iomem *)ioremap_nocache(dinfo->mmio_base_phys,
+ INTEL_REG_SIZE);
+ if (!dinfo->mmio_base) {
+ ERR_MSG("Cannot remap MMIO region.\n");
+ cleanup(dinfo);
+ return -ENODEV;
+ }
+
if (dinfo->accel) {
if (!(dinfo->gtt_ring_mem =
agp_allocate_memory(bridge, dinfo->ring.size >> 12,
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -643,8 +643,8 @@ fb_pan_display(struct fb_info *info, str
int
fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
{
- int err;
-
+ int err, flags = info->flags;
+
if (var->activate & FB_ACTIVATE_INV_MODE) {
struct fb_videomode mode1, mode2;
int ret = 0;
@@ -697,7 +697,7 @@ fb_set_var(struct fb_info *info, struct
!list_empty(>modelist))
err = fb_add_videomode(, >modelist);
- if (!err && info->flags & FBINFO_MISC_USEREVENT) {
+ if (!err && flags & FBINFO_MISC_USEREVENT) {
struct fb_event event;
int evnt = (var->activate & FB_ACTIVATE_ALL) ?
FB_EVENT_MODE_CHANGE_ALL :
Re: Linux-2.6.13-rc7
On Fri, 26 Aug 2005 00:23:40 +0800
"Antonino A. Daplas" <[EMAIL PROTECTED]> wrote:
> Sebastian Kaergel wrote:
> > On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
> > Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> >> Sylvain Meyer:
> >> intelfb: Do not ioremap entire graphics aperture
>
> Probably this one. If vram is less than stolen size, intelfb
> will only ioremap the framebuffer memory, excluding the
> ringbuffer and the cursor memory.
>
> Try booting with video=intelfb:accel:0,nohwcursor:0. If you get
> a display, try this patch.
>
> CC'ed Sylvain.
>
> Signed-off-by: Antonino Daplas <[EMAIL PROTECTED]>
> ---
Hi,
thanks for your quick reply, but it did not work. the screen remains
black when booting with video=intelfb:accel:0,{,no}hwcursor:0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Sebastian Kaergel wrote:
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
Antonino A. Daplas:
intelfb/fbdev: Save info->flags in a local variable
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
Probably this one. If vram is less than stolen size, intelfb
will only ioremap the framebuffer memory, excluding the
ringbuffer and the cursor memory.
Try booting with video=intelfb:accel:0,nohwcursor:0. If you get
a display, try this patch.
CC'ed Sylvain.
Signed-off-by: Antonino Daplas <[EMAIL PROTECTED]>
---
diff --git a/drivers/video/intelfb/intelfbdrv.c
b/drivers/video/intelfb/intelfbdrv.c
--- a/drivers/video/intelfb/intelfbdrv.c
+++ b/drivers/video/intelfb/intelfbdrv.c
@@ -502,7 +502,7 @@ intelfb_pci_register(struct pci_dev *pde
struct agp_bridge_data *bridge;
int aperture_bar = 0;
int mmio_bar = 1;
- int offset;
+ int offset, remap;
DBG_MSG("intelfb_pci_register\n");
@@ -662,11 +662,15 @@ intelfb_pci_register(struct pci_dev *pde
+ (dinfo->cursor.size >> 12);
}
+ if (dinfo->fbmem_gart)
+ remap = (dinfo->fb.offset << 12) + dinfo->fb.size;
+ else
+ remap = (dinfo->cursor.offset << 12) + dinfo->cursor.size;
+
/* Map the fb and MMIO regions */
/* ioremap only up to the end of used aperture */
dinfo->aperture.virtual = (u8 __iomem *)ioremap_nocache
- (dinfo->aperture.physical, (dinfo->fb.offset << 12)
-+ dinfo->fb.size);
+ (dinfo->aperture.physical, remap);
if (!dinfo->aperture.virtual) {
ERR_MSG("Cannot remap FB region.\n");
cleanup(dinfo);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > Antonino A. Daplas: > intelfb/fbdev: Save info->flags in a local variable > Sylvain Meyer: > intelfb: Do not ioremap entire graphics aperture One of these changes broke intelfb. The same .config from 2.6.13-rc6 does no longer work for -rc7. After booting the screen stays black, but i can type blindly. I can also start X. dmesg does not show anything unusual. any ideas? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, 25 Aug 2005, Al Viro wrote:
> On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote:
> > I have been a little out of it for a while on the sun3 stuffs, I'll admit
> > (cursed day job), but I really, really intend to get recent 2.6 running
> > again. Knowing that the rest of m68k is at least compiling is a good
> > start point. Still, I'm going with Geert, and I'm not sure where the
> > compile regressions would have come from (outside of the video/serial
> > drivers, which don't compile in m68k CVS either).
> >
> > What compile failures are you seeing?
>
> After looking at that for a while... It's the second hairball in there ;-)
> flush_icache_range()/flush_icache_user_range() stuff, with all related
> fun. Note that mainline has flush_ichace_range() in memory.c, which is
> not picked by sun3.
Indeed, the cache flush routines have to be moved to a separate file, as per
376-cache.diff. But that one depends on 362-cache.diff, that's why it's still
in my POSTPONED queue, until the originator has pushed that one upstream.
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, 25 Aug 2005, Al Viro wrote: > On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote: > > > I have been a little out of it for a while on the sun3 stuffs, I'll admit > > (cursed day job), but I really, really intend to get recent 2.6 running > > again. Knowing that the rest of m68k is at least compiling is a good > > start point. Still, I'm going with Geert, and I'm not sure where the > > compile regressions would have come from (outside of the video/serial > > drivers, which don't compile in m68k CVS either). > > > > What compile failures are you seeing? > > After looking at that for a while... It's the second hairball in there ;-) > flush_icache_range()/flush_icache_user_range() stuff, with all related > fun. Note that mainline has flush_ichace_range() in memory.c, which is > not picked by sun3. Huh, my last compiling 2.6 sun3 tree ((old) m68k CVS) has those in arch/m68k/mm/cache.c, which sun3 did use. Ok, sounds like I need to make sure those are broken out sanely. I'm pretty sure memory.c is a bad place for that, since (as you observed), it's motorola-mmu only code (or, at least, was...) I'm considerably less scared now. :) -- Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote: > I have been a little out of it for a while on the sun3 stuffs, I'll admit > (cursed day job), but I really, really intend to get recent 2.6 running > again. Knowing that the rest of m68k is at least compiling is a good > start point. Still, I'm going with Geert, and I'm not sure where the > compile regressions would have come from (outside of the video/serial > drivers, which don't compile in m68k CVS either). > > What compile failures are you seeing? After looking at that for a while... It's the second hairball in there ;-) flush_icache_range()/flush_icache_user_range() stuff, with all related fun. Note that mainline has flush_ichace_range() in memory.c, which is not picked by sun3. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: > I really wanted to release a 2.6.13, but there's been enough changes > while we've been waiting for other issues to resolve that I think it's > best to do a -rc7 first. There's something strange going on with either ACPI or cpufreq. When the system boots, I see that the CPU is correctly detected as a 1200 MHz mobile Athlon, but once I log in /proc/cpuinfo says it's 2.6 or 3.6 GHz CPU. I don't have the laptop with me right now, but I'll send the boot messages tonight. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, 25 Aug 2005, Geert Uytterhoeven wrote: > Can't you use the plain m68k toolchain? I always used a m68k-linux-gcc 3.3.3 > for my uClinux experiments. > > > sun3 is seriously broken and I doubt that we'll see any takers for testing > > 2.6 on those anyway ;-) Hey, I'm writing this on a sun3! :) > However, a few months ago it was still known to work in m68k CVS (ask Sammy). > And I didn't see any real compile regressions since then. Looks like the last rev which really worked on the sun3 was 2.6.5, which did work alright from m68k CVS (I did have another patch which needed to be applied to actually get it to run, but that appears to have been only fixes for the video/serial drivers, nothing "core"). I have been a little out of it for a while on the sun3 stuffs, I'll admit (cursed day job), but I really, really intend to get recent 2.6 running again. Knowing that the rest of m68k is at least compiling is a good start point. Still, I'm going with Geert, and I'm not sure where the compile regressions would have come from (outside of the video/serial drivers, which don't compile in m68k CVS either). What compile failures are you seeing? -- Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Wed, 24 Aug 2005, Al Viro wrote:
> It does, no (build) regressions. BTW, tree is not far from allmodconfig
> buildable on a bunch of targets now - yesterday pile of fixes was about
> half of the set needed for that. Most of the remaining stuff is for
> m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
> and if Geert ACKs them, we will be _very_ close to having 2.6.13 build
They look OK to me (sorry, I'm not in a position to really test them).
For thread_info related stuff, please coordinate with Roman.
> out of the box on the following set:
> alpha, amd64, arm (RPC and versatile being tracked), i386, ia64, m32r,
> m68k (!SUN3), ppc (6xx, 44x, chestnut being tracked), ppc64, sparc,
> sparc64, s390, s390x, uml-i386, uml-amd64.
Very nice! That must be a historical record ;-)
> v850, m68knommu: gcc gives ICE on attempt to build cross-toolchain
Can't you use the plain m68k toolchain? I always used a m68k-linux-gcc 3.3.3
for my uClinux experiments.
> sun3 is seriously broken and I doubt that we'll see any takers for testing
> 2.6 on those anyway ;-)
However, a few months ago it was still known to work in m68k CVS (ask Sammy).
And I didn't see any real compile regressions since then.
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Wed, Aug 24, 2005 at 10:38:59PM +0100, Al Viro wrote:
> On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:
> > On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote:
> > > Most of the remaining stuff is for
> > > m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
> > > and if Geert ACKs them, we will be _very_ close to having 2.6.13 build
> > > out of the box on the following set:
> > > alpha,
> >
> > Do I understand correctly that alpha in "--><-- close" list?
> >
> > 2.6.13-rc7, alpha, allmodconfig:
> >
> > LD .tmp_vmlinux1
> > net/built-in.o: In function `kmalloc':
> > include/linux/slab.h:92: undefined reference to
> > `__you_cannot_kmalloc_that_much'
> > include/linux/slab.h:92: undefined reference to
> > `__you_cannot_kmalloc_that_much'
> >
> > Guilty: net/ipv4/route.c
> >
> > $ nm net/ipv4/route.o | grep kmalloc
> > U __you_cannot_kmalloc_that_much
>
> Not here...
>
> CC arch/alpha/lib/udelay.o
> LD .tmp_vmlinux1
[snip]
> Allmodconfig on alpha, alpha-linux-gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5).
Mine is alpha-unknown-linux-gnu-gcc (GCC) 3.4.4 (Gentoo 3.4.4)
> Which place triggers it in your build?
net/ipv4/route.c:3152, call to rt_hash_lock_init().
>From preprocessed source (reformatted):
---
typedef struct {
volatile unsigned int lock;
int on_cpu;
int line_no;
void *previous;
struct task_struct * task;
const char *base_file;
} spinlock_t;
static inline void *kmalloc(size_t size, unsigned int flags)
{
if (__builtin_constant_p(size)) {
int i = 0;
if (size <= 64) goto found; else i++;
if (size <= 128) goto found; else i++;
if (size <= 192) goto found; else i++;
if (size <= 256) goto found; else i++;
if (size <= 512) goto found; else i++;
if (size <= 1024) goto found; else i++;
if (size <= 2048) goto found; else i++;
if (size <= 4096) goto found; else i++;
if (size <= 8192) goto found; else i++;
if (size <= 16384) goto found; else i++;
if (size <= 32768) goto found; else i++;
if (size <= 65536) goto found; else i++;
if (size <= 131072) goto found; else i++;
{
extern void __you_cannot_kmalloc_that_much(void);
__you_cannot_kmalloc_that_much();
}
[snip]
---
{
int i;
rt_hash_locks = kmalloc(sizeof(spinlock_t) * 4096, (0x10u | 0x40u |
0x80u));
if (!rt_hash_locks)
panic("IP: failed to allocate rt_hash_locks\n");
for (i = 0; i < 4096; i++)
do {
*(_hash_locks[i]) = (spinlock_t){ 0, -1, 0,
((void *)0), ((void *)0), ((void *)0) };
} while(0);
};
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Wed, Aug 24, 2005 at 10:38:59PM +0100, Al Viro wrote:
On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:
On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote:
Most of the remaining stuff is for
m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
and if Geert ACKs them, we will be _very_ close to having 2.6.13 build
out of the box on the following set:
alpha,
Do I understand correctly that alpha in close list?
2.6.13-rc7, alpha, allmodconfig:
LD .tmp_vmlinux1
net/built-in.o: In function `kmalloc':
include/linux/slab.h:92: undefined reference to
`__you_cannot_kmalloc_that_much'
include/linux/slab.h:92: undefined reference to
`__you_cannot_kmalloc_that_much'
Guilty: net/ipv4/route.c
$ nm net/ipv4/route.o | grep kmalloc
U __you_cannot_kmalloc_that_much
Not here...
CC arch/alpha/lib/udelay.o
LD .tmp_vmlinux1
[snip]
Allmodconfig on alpha, alpha-linux-gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5).
Mine is alpha-unknown-linux-gnu-gcc (GCC) 3.4.4 (Gentoo 3.4.4)
Which place triggers it in your build?
net/ipv4/route.c:3152, call to rt_hash_lock_init().
From preprocessed source (reformatted):
---
typedef struct {
volatile unsigned int lock;
int on_cpu;
int line_no;
void *previous;
struct task_struct * task;
const char *base_file;
} spinlock_t;
static inline void *kmalloc(size_t size, unsigned int flags)
{
if (__builtin_constant_p(size)) {
int i = 0;
if (size = 64) goto found; else i++;
if (size = 128) goto found; else i++;
if (size = 192) goto found; else i++;
if (size = 256) goto found; else i++;
if (size = 512) goto found; else i++;
if (size = 1024) goto found; else i++;
if (size = 2048) goto found; else i++;
if (size = 4096) goto found; else i++;
if (size = 8192) goto found; else i++;
if (size = 16384) goto found; else i++;
if (size = 32768) goto found; else i++;
if (size = 65536) goto found; else i++;
if (size = 131072) goto found; else i++;
{
extern void __you_cannot_kmalloc_that_much(void);
__you_cannot_kmalloc_that_much();
}
[snip]
---
{
int i;
rt_hash_locks = kmalloc(sizeof(spinlock_t) * 4096, (0x10u | 0x40u |
0x80u));
if (!rt_hash_locks)
panic(IP: failed to allocate rt_hash_locks\n);
for (i = 0; i 4096; i++)
do {
*(rt_hash_locks[i]) = (spinlock_t){ 0, -1, 0,
((void *)0), ((void *)0), ((void *)0) };
} while(0);
};
---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Wed, 24 Aug 2005, Al Viro wrote:
It does, no (build) regressions. BTW, tree is not far from allmodconfig
buildable on a bunch of targets now - yesterday pile of fixes was about
half of the set needed for that. Most of the remaining stuff is for
m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
and if Geert ACKs them, we will be _very_ close to having 2.6.13 build
They look OK to me (sorry, I'm not in a position to really test them).
For thread_info related stuff, please coordinate with Roman.
out of the box on the following set:
alpha, amd64, arm (RPC and versatile being tracked), i386, ia64, m32r,
m68k (!SUN3), ppc (6xx, 44x, chestnut being tracked), ppc64, sparc,
sparc64, s390, s390x, uml-i386, uml-amd64.
Very nice! That must be a historical record ;-)
v850, m68knommu: gcc gives ICE on attempt to build cross-toolchain
Can't you use the plain m68k toolchain? I always used a m68k-linux-gcc 3.3.3
for my uClinux experiments.
sun3 is seriously broken and I doubt that we'll see any takers for testing
2.6 on those anyway ;-)
However, a few months ago it was still known to work in m68k CVS (ask Sammy).
And I didn't see any real compile regressions since then.
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, 25 Aug 2005, Geert Uytterhoeven wrote: Can't you use the plain m68k toolchain? I always used a m68k-linux-gcc 3.3.3 for my uClinux experiments. sun3 is seriously broken and I doubt that we'll see any takers for testing 2.6 on those anyway ;-) Hey, I'm writing this on a sun3! :) However, a few months ago it was still known to work in m68k CVS (ask Sammy). And I didn't see any real compile regressions since then. Looks like the last rev which really worked on the sun3 was 2.6.5, which did work alright from m68k CVS (I did have another patch which needed to be applied to actually get it to run, but that appears to have been only fixes for the video/serial drivers, nothing core). I have been a little out of it for a while on the sun3 stuffs, I'll admit (cursed day job), but I really, really intend to get recent 2.6 running again. Knowing that the rest of m68k is at least compiling is a good start point. Still, I'm going with Geert, and I'm not sure where the compile regressions would have come from (outside of the video/serial drivers, which don't compile in m68k CVS either). What compile failures are you seeing? -- Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote: I have been a little out of it for a while on the sun3 stuffs, I'll admit (cursed day job), but I really, really intend to get recent 2.6 running again. Knowing that the rest of m68k is at least compiling is a good start point. Still, I'm going with Geert, and I'm not sure where the compile regressions would have come from (outside of the video/serial drivers, which don't compile in m68k CVS either). What compile failures are you seeing? After looking at that for a while... It's the second hairball in there ;-) flush_icache_range()/flush_icache_user_range() stuff, with all related fun. Note that mainline has flush_ichace_range() in memory.c, which is not picked by sun3. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, 25 Aug 2005, Al Viro wrote: On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote: I have been a little out of it for a while on the sun3 stuffs, I'll admit (cursed day job), but I really, really intend to get recent 2.6 running again. Knowing that the rest of m68k is at least compiling is a good start point. Still, I'm going with Geert, and I'm not sure where the compile regressions would have come from (outside of the video/serial drivers, which don't compile in m68k CVS either). What compile failures are you seeing? After looking at that for a while... It's the second hairball in there ;-) flush_icache_range()/flush_icache_user_range() stuff, with all related fun. Note that mainline has flush_ichace_range() in memory.c, which is not picked by sun3. Huh, my last compiling 2.6 sun3 tree ((old) m68k CVS) has those in arch/m68k/mm/cache.c, which sun3 did use. Ok, sounds like I need to make sure those are broken out sanely. I'm pretty sure memory.c is a bad place for that, since (as you observed), it's motorola-mmu only code (or, at least, was...) I'm considerably less scared now. :) -- Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, 25 Aug 2005, Al Viro wrote:
On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote:
I have been a little out of it for a while on the sun3 stuffs, I'll admit
(cursed day job), but I really, really intend to get recent 2.6 running
again. Knowing that the rest of m68k is at least compiling is a good
start point. Still, I'm going with Geert, and I'm not sure where the
compile regressions would have come from (outside of the video/serial
drivers, which don't compile in m68k CVS either).
What compile failures are you seeing?
After looking at that for a while... It's the second hairball in there ;-)
flush_icache_range()/flush_icache_user_range() stuff, with all related
fun. Note that mainline has flush_ichace_range() in memory.c, which is
not picked by sun3.
Indeed, the cache flush routines have to be moved to a separate file, as per
376-cache.diff. But that one depends on 362-cache.diff, that's why it's still
in my POSTPONED queue, until the originator has pushed that one upstream.
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: I really wanted to release a 2.6.13, but there's been enough changes while we've been waiting for other issues to resolve that I think it's best to do a -rc7 first. There's something strange going on with either ACPI or cpufreq. When the system boots, I see that the CPU is correctly detected as a 1200 MHz mobile Athlon, but once I log in /proc/cpuinfo says it's 2.6 or 3.6 GHz CPU. I don't have the laptop with me right now, but I'll send the boot messages tonight. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] wrote: Antonino A. Daplas: intelfb/fbdev: Save info-flags in a local variable Sylvain Meyer: intelfb: Do not ioremap entire graphics aperture One of these changes broke intelfb. The same .config from 2.6.13-rc6 does no longer work for -rc7. After booting the screen stays black, but i can type blindly. I can also start X. dmesg does not show anything unusual. any ideas? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Sebastian Kaergel wrote:
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds [EMAIL PROTECTED] wrote:
Antonino A. Daplas:
intelfb/fbdev: Save info-flags in a local variable
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
Probably this one. If vram is less than stolen size, intelfb
will only ioremap the framebuffer memory, excluding the
ringbuffer and the cursor memory.
Try booting with video=intelfb:accel:0,nohwcursor:0. If you get
a display, try this patch.
CC'ed Sylvain.
Signed-off-by: Antonino Daplas [EMAIL PROTECTED]
---
diff --git a/drivers/video/intelfb/intelfbdrv.c
b/drivers/video/intelfb/intelfbdrv.c
--- a/drivers/video/intelfb/intelfbdrv.c
+++ b/drivers/video/intelfb/intelfbdrv.c
@@ -502,7 +502,7 @@ intelfb_pci_register(struct pci_dev *pde
struct agp_bridge_data *bridge;
int aperture_bar = 0;
int mmio_bar = 1;
- int offset;
+ int offset, remap;
DBG_MSG(intelfb_pci_register\n);
@@ -662,11 +662,15 @@ intelfb_pci_register(struct pci_dev *pde
+ (dinfo-cursor.size 12);
}
+ if (dinfo-fbmem_gart)
+ remap = (dinfo-fb.offset 12) + dinfo-fb.size;
+ else
+ remap = (dinfo-cursor.offset 12) + dinfo-cursor.size;
+
/* Map the fb and MMIO regions */
/* ioremap only up to the end of used aperture */
dinfo-aperture.virtual = (u8 __iomem *)ioremap_nocache
- (dinfo-aperture.physical, (dinfo-fb.offset 12)
-+ dinfo-fb.size);
+ (dinfo-aperture.physical, remap);
if (!dinfo-aperture.virtual) {
ERR_MSG(Cannot remap FB region.\n);
cleanup(dinfo);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Fri, 26 Aug 2005 00:23:40 +0800
Antonino A. Daplas [EMAIL PROTECTED] wrote:
Sebastian Kaergel wrote:
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds [EMAIL PROTECTED] wrote:
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
Probably this one. If vram is less than stolen size, intelfb
will only ioremap the framebuffer memory, excluding the
ringbuffer and the cursor memory.
Try booting with video=intelfb:accel:0,nohwcursor:0. If you get
a display, try this patch.
CC'ed Sylvain.
Signed-off-by: Antonino Daplas [EMAIL PROTECTED]
---
patch snipped
Hi,
thanks for your quick reply, but it did not work. the screen remains
black when booting with video=intelfb:accel:0,{,no}hwcursor:0
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Sebastian Kaergel wrote:
On Fri, 26 Aug 2005 00:23:40 +0800
Antonino A. Daplas [EMAIL PROTECTED] wrote:
Sebastian Kaergel wrote:
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds [EMAIL PROTECTED] wrote:
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
Probably this one. If vram is less than stolen size, intelfb
will only ioremap the framebuffer memory, excluding the
ringbuffer and the cursor memory.
Try booting with video=intelfb:accel:0,nohwcursor:0. If you get
a display, try this patch.
CC'ed Sylvain.
Signed-off-by: Antonino Daplas [EMAIL PROTECTED]
---
patch snipped
Hi,
thanks for your quick reply, but it did not work. the screen remains
black when booting with video=intelfb:accel:0,{,no}hwcursor:0
Can you try the patch anyway?
If the patch does not fix your problem, can you revert the patches and
see which is the culprit. I'm attaching those 2 patches.
Tony
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
drivers/video/intelfb/intelfbdrv.c: needs update
Index: drivers/video/intelfb/intelfbdrv.c
===
--- 0582536f492dc10e4849053d19fec93ca72e9bfe/drivers/video/intelfb/intelfbdrv.c
(mode:100644)
+++ uncommitted/drivers/video/intelfb/intelfbdrv.c (mode:100644)
@@ -579,23 +579,6 @@
return -ENODEV;
}
- /* Map the fb and MMIO regions */
- dinfo-aperture.virtual = (u8 __iomem *)ioremap_nocache
- (dinfo-aperture.physical, dinfo-aperture.size);
- if (!dinfo-aperture.virtual) {
- ERR_MSG(Cannot remap FB region.\n);
- cleanup(dinfo);
- return -ENODEV;
- }
- dinfo-mmio_base =
- (u8 __iomem *)ioremap_nocache(dinfo-mmio_base_phys,
- INTEL_REG_SIZE);
- if (!dinfo-mmio_base) {
- ERR_MSG(Cannot remap MMIO region.\n);
- cleanup(dinfo);
- return -ENODEV;
- }
-
/* Get the chipset info. */
dinfo-pci_chipset = pdev-device;
@@ -679,6 +662,26 @@
}
/* Allocate memories (which aren't stolen) */
+ /* Map the fb and MMIO regions */
+ /* ioremap only up to the end of used aperture */
+ dinfo-aperture.virtual = (u8 __iomem *)ioremap_nocache
+ (dinfo-aperture.physical, ((offset + dinfo-fb.offset) 12)
++ dinfo-fb.size);
+ if (!dinfo-aperture.virtual) {
+ ERR_MSG(Cannot remap FB region.\n);
+ cleanup(dinfo);
+ return -ENODEV;
+ }
+
+ dinfo-mmio_base =
+ (u8 __iomem *)ioremap_nocache(dinfo-mmio_base_phys,
+ INTEL_REG_SIZE);
+ if (!dinfo-mmio_base) {
+ ERR_MSG(Cannot remap MMIO region.\n);
+ cleanup(dinfo);
+ return -ENODEV;
+ }
+
if (dinfo-accel) {
if (!(dinfo-gtt_ring_mem =
agp_allocate_memory(bridge, dinfo-ring.size 12,
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -643,8 +643,8 @@ fb_pan_display(struct fb_info *info, str
int
fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
{
- int err;
-
+ int err, flags = info-flags;
+
if (var-activate FB_ACTIVATE_INV_MODE) {
struct fb_videomode mode1, mode2;
int ret = 0;
@@ -697,7 +697,7 @@ fb_set_var(struct fb_info *info, struct
!list_empty(info-modelist))
err = fb_add_videomode(mode, info-modelist);
- if (!err info-flags FBINFO_MISC_USEREVENT) {
+ if (!err flags FBINFO_MISC_USEREVENT) {
struct fb_event event;
int evnt = (var-activate FB_ACTIVATE_ALL) ?
FB_EVENT_MODE_CHANGE_ALL :
Re: Linux-2.6.13-rc7
Sorry but could you re-explain me the problem. Tony, you've only
CC'ed me the end of the story.
Just a correction the options are video=intelfb:accel=0,hwcursor=0
with = and not :
Regards
Sylvain
Sebastian Kaergel a écrit:
On Fri, 26 Aug 2005 00:23:40 +0800
Antonino A. Daplas [EMAIL PROTECTED] wrote:
Sebastian Kaergel wrote:
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds [EMAIL PROTECTED] wrote:
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
Probably this one. If vram is less than stolen size, intelfb
will only ioremap the framebuffer memory, excluding the
ringbuffer and the cursor memory.
Try booting with video=intelfb:accel:0,nohwcursor:0. If you get
a display, try this patch.
CC'ed Sylvain.
Signed-off-by: Antonino Daplas [EMAIL PROTECTED]
---
patch snipped
Hi,
thanks for your quick reply, but it did not work. the screen remains
black when booting with video=intelfb:accel:0,{,no}hwcursor:0
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, Aug 25, 2005 at 11:27:32AM +0400, Alexey Dobriyan wrote:
Mine is alpha-unknown-linux-gnu-gcc (GCC) 3.4.4 (Gentoo 3.4.4)
Which place triggers it in your build?
net/ipv4/route.c:3152, call to rt_hash_lock_init().
From preprocessed source (reformatted):
---
typedef struct {
volatile unsigned int lock;
int on_cpu;
int line_no;
void *previous;
struct task_struct * task;
const char *base_file;
} spinlock_t;
static inline void *kmalloc(size_t size, unsigned int flags)
Oh, lovely...
a) gcc4 on alpha refuses to make that inline
b) bug is real, indeed - spinlock debugging + 32 CPU = panic in ip_rt_init()
IMO that's a question to rth: why do we really need to block always_inline
on alpha?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, Aug 25, 2005 at 08:07:55PM +0100, Al Viro wrote: IMO that's a question to rth: why do we really need to block always_inline on alpha? Because I use extern inline in the proper way. That is, I have both inline and out-of-line versions of some routines. These routines have their address taken to be put into the alpha_machine_vector structures, so we're guaranteed that they'll be out-of-line at least once. But if you define inline to always_inline, the compiler complains when its forced to fall back to the out-of-line copy. And rightly so -- the feature was INVENTED for using compiler intrinsics that would in fact not produce valid assembly unless certain parameters are constants. I've complained about this before. You always-inline savages have obsconded with ALL THREE inline keywords -- inline, __inline and __inline__ -- so there is in fact no way to accomplish what I want. So in a fit of pique I've locally undone not just one, but all of the always-inline crap. All that said, something's wrong if we couldn't generate an out-of-line copy of kmalloc. The entire block protected by __builtin_constant_p should have been eliminated. File a gcc bugzilla report. r~ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, Aug 25, 2005 at 03:16:49PM -0700, Richard Henderson wrote:
On Thu, Aug 25, 2005 at 08:07:55PM +0100, Al Viro wrote:
IMO that's a question to rth: why do we really need to block always_inline
on alpha?
Because I use extern inline in the proper way. That is, I have both
inline and out-of-line versions of some routines. These routines have
their address taken to be put into the alpha_machine_vector structures,
so we're guaranteed that they'll be out-of-line at least once.
But if you define inline to always_inline, the compiler complains when
its forced to fall back to the out-of-line copy. And rightly so -- the
feature was INVENTED for using compiler intrinsics that would in fact
not produce valid assembly unless certain parameters are constants.
I've complained about this before. You always-inline savages have
obsconded with ALL THREE inline keywords -- inline, __inline and
__inline__ -- so there is in fact no way to accomplish what I want.
So in a fit of pique I've locally undone not just one, but all of the
always-inline crap.
All that said, something's wrong if we couldn't generate an out-of-line
copy of kmalloc. The entire block protected by __builtin_constant_p
should have been eliminated. File a gcc bugzilla report.
It is eliminated. As the result, the compile-time checks disappear.
In this case it's more or less harmless - we miss some bugs that could
be caught at compile time, but that's it. In case of e.g. xchg() (same
technics of calling undefined function in the code that gets eliminated
if everything's right) it gave genuine bugs - gcc decided to create an
uninlined copy and to hell it went:
static inline unsigned long
__xchg(volatile void *ptr, unsigned long x, int size)
{
switch (size) {
case 1:
return __xchg_u8(ptr, x);
case 2:
return __xchg_u16(ptr, x);
case 4:
return __xchg_u32(ptr, x);
case 8:
return __xchg_u64(ptr, x);
}
__xchg_called_with_bad_pointer();
return x;
}
#define xchg(ptr,x) \
({ \
__typeof__(*(ptr)) _x_ = (x); \
(__typeof__(*(ptr))) __xchg((ptr), (unsigned long)_x_, sizeof(*(ptr))); \
})
blows to hell, since we have no way to tell gcc that it should _never_
be done non-inlined. Well, no way short of making __xchg a macro...
So what do you propose to use for that class of compile-time checks?
#define whenever they are used?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Sorry. Here's the start of the thread. Tony On Tue, 23 Aug 2005 22:08:13 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] wrote: Antonino A. Daplas: intelfb/fbdev: Save info-flags in a local variable Sylvain Meyer: intelfb: Do not ioremap entire graphics aperture One of these changes broke intelfb. The same .config from 2.6.13-rc6 does no longer work for -rc7. After booting the screen stays black, but i can type blindly. I can also start X. dmesg does not show anything unusual. any ideas? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
root:sleipner:~# modprobe hotkey FATAL: Error inserting hotkey (/lib/modules/2.6.13-rc7/kernel/drivers/acpi/hotkey.ko): No such device Not that I care, but it at least loaded in -rc6 and created the /proc/acpi/hotkey directory with its content. When the revolution comes, the author of acpi-hotkey.txt will face the wall first. Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7 : OK
Hello, On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: > > Hullo. > > I really wanted to release a 2.6.13, but there's been enough changes > while we've been waiting for other issues to resolve that I think it's > best to do a -rc7 first. > > Most of the -rc7 changes are pretty trivial, either one-liners or > affecting some particular specific driver or unusual configuration. The > shortlog (appended) should give a pretty good idea of what's up. Well, it's been running here for a few hours this evening, and I must say that I have not noticed anything strange yet (except the printk timestamps which switch to zero twice during boot and start with funny values, but that's not important). The box is a dual-k7 with aic7xxx, and NFSv3 over an e1000 NIC. Tested with SMP and preempt enabled. > > Linus Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote: > On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote: > > Most of the remaining stuff is for > > m68k (and applies both to Linus' tree and m68k CVS); I'll send that today > > and if Geert ACKs them, we will be _very_ close to having 2.6.13 build > > out of the box on the following set: > > alpha, > > Do I understand correctly that alpha in "--><-- close" list? > > 2.6.13-rc7, alpha, allmodconfig: > > LD .tmp_vmlinux1 > net/built-in.o: In function `kmalloc': > include/linux/slab.h:92: undefined reference to > `__you_cannot_kmalloc_that_much' > include/linux/slab.h:92: undefined reference to > `__you_cannot_kmalloc_that_much' > > Guilty: net/ipv4/route.c > > $ nm net/ipv4/route.o | grep kmalloc > U __you_cannot_kmalloc_that_much Not here... CC arch/alpha/lib/udelay.o AR arch/alpha/lib/lib.a GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 KSYM.tmp_kallsyms1.S AS .tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM.tmp_kallsyms2.S AS .tmp_kallsyms2.o LD .tmp_vmlinux3 KSYM.tmp_kallsyms3.S AS .tmp_kallsyms3.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map STRIP arch/alpha/boot/vmlinux Allmodconfig on alpha, alpha-linux-gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5). Which place triggers it in your build? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:
> > sh64: need kernel headers that would make glibc happy enough
> > to build libc headers for that puppy;
>
> binutils already compiled. Will drop a line. Or file a bug. :-\
By some miracle gcc is also compiled. As of now (sh64, allmodconfig):
arch/sh64/kernel/pci_sh5.c: In function `map_cayman_irq':
arch/sh64/kernel/pci_sh5.c:334: error: `IRQ_P2INTA' undeclared
arch/sh64/kernel/dma.c: In function `init_dma':
arch/sh64/kernel/dma.c:248: error: storage size of 'vcr' isn't known
arch/sh64/mm/hugetlbpage.c: At top level:
arch/sh64/mm/hugetlbpage.c:84: error: conflicting types for
'huge_ptep_get_and_clear'
include/linux/hugetlb.h:64: error: previous declaration of
'huge_ptep_get_and_clear' was here
arch/sh64/mm/hugetlbpage.c: In function `huge_ptep_get_and_clear':
arch/sh64/mm/hugetlbpage.c:89: error: `i' undeclared
arch/sh64/mm/hugetlbpage.c:90:16: macro "pte_clear" requires 3 arguments, but
only 1 given
arch/sh64/mm/hugetlbpage.c:90: error: `pte_clear' undeclared (first use in this
function)
arch/sh64/mm/hugetlbpage.c:91: error: `pte' undeclared (first use in this
function)
arch/sh64/mach-sim/setup.c:25:11: error: unable to open 'asm/addrspace.h'
exists only in asm-{sh, m32r, mips}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote: > Most of the remaining stuff is for > m68k (and applies both to Linus' tree and m68k CVS); I'll send that today > and if Geert ACKs them, we will be _very_ close to having 2.6.13 build > out of the box on the following set: > alpha, Do I understand correctly that alpha in "--><-- close" list? 2.6.13-rc7, alpha, allmodconfig: LD .tmp_vmlinux1 net/built-in.o: In function `kmalloc': include/linux/slab.h:92: undefined reference to `__you_cannot_kmalloc_that_much' include/linux/slab.h:92: undefined reference to `__you_cannot_kmalloc_that_much' Guilty: net/ipv4/route.c $ nm net/ipv4/route.o | grep kmalloc U __you_cannot_kmalloc_that_much > sh64: need kernel headers that would make glibc happy enough > to build libc headers for that puppy; binutils already compiled. Will drop a line. Or file a bug. :-\ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Wed, Aug 24, 2005 at 11:43:51AM -0700, Paul Jackson wrote: > Al Viro wrote: > > ... breaks ppc64 since there we have node_to_cpumask() done as inlined > > function, not a macro. So we get __first_cpu(_to_cpumask(...),...), > > with obvious consequences. > > I sent a patch for this a few hours ago, thanks to Paul Mackerras's report: > > [PATCH 2.6.13-rc6] cpu_exclusive sched domains build fix > > It just makes a local copy of the cpumask_t in a local variable on the stack. > > I'm still a couple of hours from actually verifying that ppc64 builds with > this - due to unrelated confusions on my end. Perhaps you or Mackerras will > report in first, to verify if this patch works as advertised. It does, no (build) regressions. BTW, tree is not far from allmodconfig buildable on a bunch of targets now - yesterday pile of fixes was about half of the set needed for that. Most of the remaining stuff is for m68k (and applies both to Linus' tree and m68k CVS); I'll send that today and if Geert ACKs them, we will be _very_ close to having 2.6.13 build out of the box on the following set: alpha, amd64, arm (RPC and versatile being tracked), i386, ia64, m32r, m68k (!SUN3), ppc (6xx, 44x, chestnut being tracked), ppc64, sparc, sparc64, s390, s390x, uml-i386, uml-amd64. All of these - with allmodconfig, alpha, amd64 and i386 being tracked separately as SMP and UP. Missing targets: frv: need newer toolchain on build box mips, parisc: need out-of-tree patches v850, m68knommu: gcc gives ICE on attempt to build cross-toolchain h8300: binutils in FC4 doesn't know what to do with that target, have not tried that on sarge yet. sh, sh64: need kernel headers that would make glibc happy enough to build libc headers for that puppy; I don't have them cris, xtensa: haven't looked into those arm26: needs gcc3 since gcc4 had dropped that target; I might take a look into that on a sarge-based build box someday. sun3 is seriously broken and I doubt that we'll see any takers for testing 2.6 on those anyway ;-) A bunch of arm and ppc subarchitectures are not covered yet - I can add those to build setup, just give me a list in order of preference. Or ask me how to set up a cross-build farm of your own... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Al Viro wrote: > ... breaks ppc64 since there we have node_to_cpumask() done as inlined > function, not a macro. So we get __first_cpu(_to_cpumask(...),...), > with obvious consequences. I sent a patch for this a few hours ago, thanks to Paul Mackerras's report: [PATCH 2.6.13-rc6] cpu_exclusive sched domains build fix It just makes a local copy of the cpumask_t in a local variable on the stack. I'm still a couple of hours from actually verifying that ppc64 builds with this - due to unrelated confusions on my end. Perhaps you or Mackerras will report in first, to verify if this patch works as advertised. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Wed, Aug 24, 2005 at 07:43:42AM +0100, Al Viro wrote: > On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: > > > cpu_exclusive sched domains on partial nodes temp fix > > ... breaks ppc64 since there we have node_to_cpumask() done as inlined > function, not a macro. So we get __first_cpu(_to_cpumask(...),...), > with obvious consequences. > > Locally I'm turning node_to_cpumask() into define, just to see what else > had changed in the build, but we probably want saner solution for that > one... Not sure why this patch was included. I had reported yesterday that it hangs up ppc64 on doing some exclusive cpuset operations. (I had fixed the compile problem by having a temp for the cpumask variable) So this patch is not ready to go in just yet. I am working on the fix, hope to have it soon -Dinakar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: > cpu_exclusive sched domains on partial nodes temp fix ... breaks ppc64 since there we have node_to_cpumask() done as inlined function, not a macro. So we get __first_cpu(_to_cpumask(...),...), with obvious consequences. Locally I'm turning node_to_cpumask() into define, just to see what else had changed in the build, but we probably want saner solution for that one... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Wed, Aug 24, 2005 at 07:43:42AM +0100, Al Viro wrote: On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: cpu_exclusive sched domains on partial nodes temp fix ... breaks ppc64 since there we have node_to_cpumask() done as inlined function, not a macro. So we get __first_cpu(node_to_cpumask(...),...), with obvious consequences. Locally I'm turning node_to_cpumask() into define, just to see what else had changed in the build, but we probably want saner solution for that one... Not sure why this patch was included. I had reported yesterday that it hangs up ppc64 on doing some exclusive cpuset operations. (I had fixed the compile problem by having a temp for the cpumask variable) So this patch is not ready to go in just yet. I am working on the fix, hope to have it soon -Dinakar - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Al Viro wrote: ... breaks ppc64 since there we have node_to_cpumask() done as inlined function, not a macro. So we get __first_cpu(node_to_cpumask(...),...), with obvious consequences. I sent a patch for this a few hours ago, thanks to Paul Mackerras's report: [PATCH 2.6.13-rc6] cpu_exclusive sched domains build fix It just makes a local copy of the cpumask_t in a local variable on the stack. I'm still a couple of hours from actually verifying that ppc64 builds with this - due to unrelated confusions on my end. Perhaps you or Mackerras will report in first, to verify if this patch works as advertised. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.925.600.0401 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Wed, Aug 24, 2005 at 11:43:51AM -0700, Paul Jackson wrote: Al Viro wrote: ... breaks ppc64 since there we have node_to_cpumask() done as inlined function, not a macro. So we get __first_cpu(node_to_cpumask(...),...), with obvious consequences. I sent a patch for this a few hours ago, thanks to Paul Mackerras's report: [PATCH 2.6.13-rc6] cpu_exclusive sched domains build fix It just makes a local copy of the cpumask_t in a local variable on the stack. I'm still a couple of hours from actually verifying that ppc64 builds with this - due to unrelated confusions on my end. Perhaps you or Mackerras will report in first, to verify if this patch works as advertised. It does, no (build) regressions. BTW, tree is not far from allmodconfig buildable on a bunch of targets now - yesterday pile of fixes was about half of the set needed for that. Most of the remaining stuff is for m68k (and applies both to Linus' tree and m68k CVS); I'll send that today and if Geert ACKs them, we will be _very_ close to having 2.6.13 build out of the box on the following set: alpha, amd64, arm (RPC and versatile being tracked), i386, ia64, m32r, m68k (!SUN3), ppc (6xx, 44x, chestnut being tracked), ppc64, sparc, sparc64, s390, s390x, uml-i386, uml-amd64. All of these - with allmodconfig, alpha, amd64 and i386 being tracked separately as SMP and UP. Missing targets: frv: need newer toolchain on build box mips, parisc: need out-of-tree patches v850, m68knommu: gcc gives ICE on attempt to build cross-toolchain h8300: binutils in FC4 doesn't know what to do with that target, have not tried that on sarge yet. sh, sh64: need kernel headers that would make glibc happy enough to build libc headers for that puppy; I don't have them cris, xtensa: haven't looked into those arm26: needs gcc3 since gcc4 had dropped that target; I might take a look into that on a sarge-based build box someday. sun3 is seriously broken and I doubt that we'll see any takers for testing 2.6 on those anyway ;-) A bunch of arm and ppc subarchitectures are not covered yet - I can add those to build setup, just give me a list in order of preference. Or ask me how to set up a cross-build farm of your own... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote: Most of the remaining stuff is for m68k (and applies both to Linus' tree and m68k CVS); I'll send that today and if Geert ACKs them, we will be _very_ close to having 2.6.13 build out of the box on the following set: alpha, Do I understand correctly that alpha in close list? 2.6.13-rc7, alpha, allmodconfig: LD .tmp_vmlinux1 net/built-in.o: In function `kmalloc': include/linux/slab.h:92: undefined reference to `__you_cannot_kmalloc_that_much' include/linux/slab.h:92: undefined reference to `__you_cannot_kmalloc_that_much' Guilty: net/ipv4/route.c $ nm net/ipv4/route.o | grep kmalloc U __you_cannot_kmalloc_that_much sh64: need kernel headers that would make glibc happy enough to build libc headers for that puppy; binutils already compiled. Will drop a line. Or file a bug. :-\ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:
sh64: need kernel headers that would make glibc happy enough
to build libc headers for that puppy;
binutils already compiled. Will drop a line. Or file a bug. :-\
By some miracle gcc is also compiled. As of now (sh64, allmodconfig):
arch/sh64/kernel/pci_sh5.c: In function `map_cayman_irq':
arch/sh64/kernel/pci_sh5.c:334: error: `IRQ_P2INTA' undeclared
arch/sh64/kernel/dma.c: In function `init_dma':
arch/sh64/kernel/dma.c:248: error: storage size of 'vcr' isn't known
arch/sh64/mm/hugetlbpage.c: At top level:
arch/sh64/mm/hugetlbpage.c:84: error: conflicting types for
'huge_ptep_get_and_clear'
include/linux/hugetlb.h:64: error: previous declaration of
'huge_ptep_get_and_clear' was here
arch/sh64/mm/hugetlbpage.c: In function `huge_ptep_get_and_clear':
arch/sh64/mm/hugetlbpage.c:89: error: `i' undeclared
arch/sh64/mm/hugetlbpage.c:90:16: macro pte_clear requires 3 arguments, but
only 1 given
arch/sh64/mm/hugetlbpage.c:90: error: `pte_clear' undeclared (first use in this
function)
arch/sh64/mm/hugetlbpage.c:91: error: `pte' undeclared (first use in this
function)
arch/sh64/mach-sim/setup.c:25:11: error: unable to open 'asm/addrspace.h'
exists only in asm-{sh, m32r, mips}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote: On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote: Most of the remaining stuff is for m68k (and applies both to Linus' tree and m68k CVS); I'll send that today and if Geert ACKs them, we will be _very_ close to having 2.6.13 build out of the box on the following set: alpha, Do I understand correctly that alpha in close list? 2.6.13-rc7, alpha, allmodconfig: LD .tmp_vmlinux1 net/built-in.o: In function `kmalloc': include/linux/slab.h:92: undefined reference to `__you_cannot_kmalloc_that_much' include/linux/slab.h:92: undefined reference to `__you_cannot_kmalloc_that_much' Guilty: net/ipv4/route.c $ nm net/ipv4/route.o | grep kmalloc U __you_cannot_kmalloc_that_much Not here... CC arch/alpha/lib/udelay.o AR arch/alpha/lib/lib.a GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 KSYM.tmp_kallsyms1.S AS .tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM.tmp_kallsyms2.S AS .tmp_kallsyms2.o LD .tmp_vmlinux3 KSYM.tmp_kallsyms3.S AS .tmp_kallsyms3.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map STRIP arch/alpha/boot/vmlinux Allmodconfig on alpha, alpha-linux-gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5). Which place triggers it in your build? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7 : OK
Hello, On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: Hullo. I really wanted to release a 2.6.13, but there's been enough changes while we've been waiting for other issues to resolve that I think it's best to do a -rc7 first. Most of the -rc7 changes are pretty trivial, either one-liners or affecting some particular specific driver or unusual configuration. The shortlog (appended) should give a pretty good idea of what's up. Well, it's been running here for a few hours this evening, and I must say that I have not noticed anything strange yet (except the printk timestamps which switch to zero twice during boot and start with funny values, but that's not important). The box is a dual-k7 with aic7xxx, and NFSv3 over an e1000 NIC. Tested with SMP and preempt enabled. Linus Regards, Willy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
root:sleipner:~# modprobe hotkey FATAL: Error inserting hotkey (/lib/modules/2.6.13-rc7/kernel/drivers/acpi/hotkey.ko): No such device Not that I care, but it at least loaded in -rc6 and created the /proc/acpi/hotkey directory with its content. When the revolution comes, the author of acpi-hotkey.txt will face the wall first. Mvh Mats Johannesson -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: cpu_exclusive sched domains on partial nodes temp fix ... breaks ppc64 since there we have node_to_cpumask() done as inlined function, not a macro. So we get __first_cpu(node_to_cpumask(...),...), with obvious consequences. Locally I'm turning node_to_cpumask() into define, just to see what else had changed in the build, but we probably want saner solution for that one... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux-2.6.13-rc7
Hullo.
I really wanted to release a 2.6.13, but there's been enough changes
while we've been waiting for other issues to resolve that I think it's
best to do a -rc7 first.
Most of the -rc7 changes are pretty trivial, either one-liners or
affecting some particular specific driver or unusual configuration. The
shortlog (appended) should give a pretty good idea of what's up.
Linus
---
Al Viro:
uml: fix the x86_64 build
[SPARC]: Fix weak aliases
jffs2: fix symlink error handling
Fix up symlink function pointers
Lots of Kconfig fixes
alpha gcc4 warnings
missing include in pcmcia_resource.c
alpha xchg fix
alpha spinlock code and bogus constraints
m32r smp.h gcc4 fixes
m32r icu_data gcc4 fixes
m32r_sio gcc4 fixes
broken inline asm on s390 (misuse of labels)
vidc gcc4 fix
emac netpoll fix
typo fix in qdio.c
qualifiers in return types - easy cases
missing exports on m32r
ad1980 makefile fix
%t... in vsnprintf
s390 __CHECKER__ ifdefs
Alexander Nyberg:
ns558 list handling fix
Alexey Dobriyan:
[NET]: Make skb->protocol __be16
freevxfs: fix breakage introduced by symlink fixes
zd1201 kmalloc size fix
Andi Kleen:
x86: Remove obsolete get_cpu_vendor call
x86_64: Don't print exceptions for ltrace
x86_64: Fix race in TSC synchronization
x86_64: Don't oops at boot when empty Opteron node has IO
Andrew Morton:
[NET]: Fix memory leak in sys_{send,recv}msg() w/compat
PCI: fix quirk-6700-fix.patch
Anton Altaparmakov:
NTFS: Fix bug in mft record writing where we forgot to set the device in
NTFS: Complete the previous fix for the unset device when mapping buffers
Antonino A. Daplas:
intelfb/fbdev: Save info->flags in a local variable
Antonino Daplas:
nvidiafb: Fix initial display corruption on certain laptops
Arnd Bergmann:
ppc64: add default config for BPA
Bartlomiej Zolnierkiewicz:
ide-floppy: fix IDEFLOPPY_TICKS_DELAY
Ben Colline:
[SPARC]: Deal with glibc changing macro names in modpost.c
Ben Dooks:
ARM: 2847/1: S3C24XX - Documentation for USB OHCI host
ARM: 2849/1: S3C24XX - USB host update (2848/1)
DM9000 - spinlock fixes
DM9000 - incorrect ioctl() handling
Benjamin Herrenschmidt:
ppc64: Fix Fan control for new PowerMac G5 2.7GHz machines
Bhavesh P. Davda:
NPTL signal delivery deadlock fix
Brian King:
ppc64: iommu vmerge fix
Christoph Hellwig:
ARM: switch fd1772.c from sleep_on to wait_event
[SPARC]: Use kthread infrastructure in envctrl
[SPARC]: Use kthread infrastructure in bbc_envctrl
[SPARC]: remove ifdef CONFIG_PCI from envctrl.c
[IA64] update CONFIG_PCI description
Christoph Lameter:
Fix ide-disk.c oops caused by hwif == NULL
Chuck Ebbert:
i386: fix incorrect FP signal code
Chuck Lever:
NFS: split nfsi->flags into two fields
NFS: use atomic bitops to manipulate flags in nfsi->flags
NFS: Introduce the use of inode->i_lock to protect fields in nfsi
Cornelia Huck:
s390: use klist in qeth driver
Dave Johnson:
[IPV4]: Fix negative timer loop with lots of ipv4 peers.
Dave Jones:
icn driver fails to unload when no hardware present
Dave Kleikamp:
Merge with /home/shaggy/git/linus-clean/
JFS: Improve sync barrier processing
Merge with /home/shaggy/git/linus-clean/
Merge with /home/shaggy/git/linus-clean/
JFS: Check for invalid inodes in jfs_delete_inode
Merge with /home/shaggy/git/linus-clean/
JFS: Fix race in txLock
Merge with /home/shaggy/git/linus-clean/
David Meybohm:
preempt race in getppid
David S. Miller:
[TG3]: Save initial PCI state before registering the netdevice.
[NETLINK]: Allocate and kill some netlink numbers.
[SPARC]: envctrl: ERR_PTR() --> PTR_ERR()
[SUNRPC]: Fix nsec --> usec conversion.
[SPARC64]: Fix 2 bugs in cpufreq drivers.
[TG3]: Update driver version and reldate.
[SPARC64]: Move kernel unaligned trap handlers into assembler file.
[TCP]: Unconditionally clear TCP_NAGLE_PUSH in skb_entail().
[TCP]: Document non-trivial locking path in tcp_v{4,6}_get_port().
[ROSE]: Fix missing unlocks in rose_route_frame()
[ROSE]: Fix typo in rose_route_frame() locking fix.
David Woodhouse:
Stop snd-powermac oopsing on non-pmac hardware.
Deepak Saxena:
Fix IXP4xx CLOCK_TICK_RATE
Dimitry Andric:
[ARM] 2850/1: Remove duplicate UART I/O mapping from s3c2410_iodesc
Dmitry Yusupov:
[TCP]: Do TSO deferral even if tail SKB can go out now.
Eric W. Biederman:
x86_64: Fix apicid versus cpu# confusion.
Evgeniy Polyakov:
w1: more debug level decrease.
Grant Coady:
ide: fix PCI_DEVIEC_ID_APPLE_UNI_N_ATA spelling
Greg Edwards:
[IA64] Refresh arch/ia64/configs/sn2_defconfig.
Greg Kroah-Hartman:
Fix manual binding infinite loop
Harald Welte:
don't try to do any NAT on untracked connections
Heikki Orsila:
[IPV4]: Debug cleanup
Herbert Xu:
[IPSEC]: Restrict socket policy loading to CAP_NET_ADMIN.
[TCP]: Adjust {p,f}ackets_out correctly in tcp_retransmit_skb()
[TCP]: Fix bug #5070: kernel BUG at
Linux-2.6.13-rc7
Hullo.
I really wanted to release a 2.6.13, but there's been enough changes
while we've been waiting for other issues to resolve that I think it's
best to do a -rc7 first.
Most of the -rc7 changes are pretty trivial, either one-liners or
affecting some particular specific driver or unusual configuration. The
shortlog (appended) should give a pretty good idea of what's up.
Linus
---
Al Viro:
uml: fix the x86_64 build
[SPARC]: Fix weak aliases
jffs2: fix symlink error handling
Fix up symlink function pointers
Lots of Kconfig fixes
alpha gcc4 warnings
missing include in pcmcia_resource.c
alpha xchg fix
alpha spinlock code and bogus constraints
m32r smp.h gcc4 fixes
m32r icu_data gcc4 fixes
m32r_sio gcc4 fixes
broken inline asm on s390 (misuse of labels)
vidc gcc4 fix
emac netpoll fix
typo fix in qdio.c
qualifiers in return types - easy cases
missing exports on m32r
ad1980 makefile fix
%t... in vsnprintf
s390 __CHECKER__ ifdefs
Alexander Nyberg:
ns558 list handling fix
Alexey Dobriyan:
[NET]: Make skb-protocol __be16
freevxfs: fix breakage introduced by symlink fixes
zd1201 kmalloc size fix
Andi Kleen:
x86: Remove obsolete get_cpu_vendor call
x86_64: Don't print exceptions for ltrace
x86_64: Fix race in TSC synchronization
x86_64: Don't oops at boot when empty Opteron node has IO
Andrew Morton:
[NET]: Fix memory leak in sys_{send,recv}msg() w/compat
PCI: fix quirk-6700-fix.patch
Anton Altaparmakov:
NTFS: Fix bug in mft record writing where we forgot to set the device in
NTFS: Complete the previous fix for the unset device when mapping buffers
Antonino A. Daplas:
intelfb/fbdev: Save info-flags in a local variable
Antonino Daplas:
nvidiafb: Fix initial display corruption on certain laptops
Arnd Bergmann:
ppc64: add default config for BPA
Bartlomiej Zolnierkiewicz:
ide-floppy: fix IDEFLOPPY_TICKS_DELAY
Ben Colline:
[SPARC]: Deal with glibc changing macro names in modpost.c
Ben Dooks:
ARM: 2847/1: S3C24XX - Documentation for USB OHCI host
ARM: 2849/1: S3C24XX - USB host update (2848/1)
DM9000 - spinlock fixes
DM9000 - incorrect ioctl() handling
Benjamin Herrenschmidt:
ppc64: Fix Fan control for new PowerMac G5 2.7GHz machines
Bhavesh P. Davda:
NPTL signal delivery deadlock fix
Brian King:
ppc64: iommu vmerge fix
Christoph Hellwig:
ARM: switch fd1772.c from sleep_on to wait_event
[SPARC]: Use kthread infrastructure in envctrl
[SPARC]: Use kthread infrastructure in bbc_envctrl
[SPARC]: remove ifdef CONFIG_PCI from envctrl.c
[IA64] update CONFIG_PCI description
Christoph Lameter:
Fix ide-disk.c oops caused by hwif == NULL
Chuck Ebbert:
i386: fix incorrect FP signal code
Chuck Lever:
NFS: split nfsi-flags into two fields
NFS: use atomic bitops to manipulate flags in nfsi-flags
NFS: Introduce the use of inode-i_lock to protect fields in nfsi
Cornelia Huck:
s390: use klist in qeth driver
Dave Johnson:
[IPV4]: Fix negative timer loop with lots of ipv4 peers.
Dave Jones:
icn driver fails to unload when no hardware present
Dave Kleikamp:
Merge with /home/shaggy/git/linus-clean/
JFS: Improve sync barrier processing
Merge with /home/shaggy/git/linus-clean/
Merge with /home/shaggy/git/linus-clean/
JFS: Check for invalid inodes in jfs_delete_inode
Merge with /home/shaggy/git/linus-clean/
JFS: Fix race in txLock
Merge with /home/shaggy/git/linus-clean/
David Meybohm:
preempt race in getppid
David S. Miller:
[TG3]: Save initial PCI state before registering the netdevice.
[NETLINK]: Allocate and kill some netlink numbers.
[SPARC]: envctrl: ERR_PTR() -- PTR_ERR()
[SUNRPC]: Fix nsec -- usec conversion.
[SPARC64]: Fix 2 bugs in cpufreq drivers.
[TG3]: Update driver version and reldate.
[SPARC64]: Move kernel unaligned trap handlers into assembler file.
[TCP]: Unconditionally clear TCP_NAGLE_PUSH in skb_entail().
[TCP]: Document non-trivial locking path in tcp_v{4,6}_get_port().
[ROSE]: Fix missing unlocks in rose_route_frame()
[ROSE]: Fix typo in rose_route_frame() locking fix.
David Woodhouse:
Stop snd-powermac oopsing on non-pmac hardware.
Deepak Saxena:
Fix IXP4xx CLOCK_TICK_RATE
Dimitry Andric:
[ARM] 2850/1: Remove duplicate UART I/O mapping from s3c2410_iodesc
Dmitry Yusupov:
[TCP]: Do TSO deferral even if tail SKB can go out now.
Eric W. Biederman:
x86_64: Fix apicid versus cpu# confusion.
Evgeniy Polyakov:
w1: more debug level decrease.
Grant Coady:
ide: fix PCI_DEVIEC_ID_APPLE_UNI_N_ATA spelling
Greg Edwards:
[IA64] Refresh arch/ia64/configs/sn2_defconfig.
Greg Kroah-Hartman:
Fix manual binding infinite loop
Harald Welte:
don't try to do any NAT on untracked connections
Heikki Orsila:
[IPV4]: Debug cleanup
Herbert Xu:
[IPSEC]: Restrict socket policy loading to CAP_NET_ADMIN.
[TCP]: Adjust {p,f}ackets_out correctly in tcp_retransmit_skb()
[TCP]: Fix bug #5070: kernel BUG at
