KOSAKI Motohiro wrote:
> Hi Michael,
>
> my server output following error message on 2.6.26-rc8-mm1.
> Is this a bug?
>
> ------------------------------------------------------------------
> tg3.c:v3.93 (May 22, 2008)
> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51
> tg3 0000:06:01.0: PCI INT A -> GSI 72 (level, low) -> IRQ 51
> firmware: requesting tigon/tg3_tso.bin
> tg3: Failed to load firmware "tigon/tg3_tso.bin"
> tg3 0000:06:01.0: PCI INT A disabled
> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51 unregistered
> tg3: probe of 0000:06:01.0 failed with error -2
> GSI 73 (level, low) -> CPU 0 (0x0001) vector 51
> tg3 0000:06:01.1: PCI INT B -> GSI 73 (level, low) -> IRQ 52
> firmware: requesting tigon/tg3_tso.bin

This change did not come from the network developers or Broadcom, so
someone else broke tg3 in -mm...

Jeff



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi Andrew,

2.6.26-rc8-mm1 kernel build fail on the powerpc,

In file included from drivers/char/hvc_rtas.c:39:
drivers/char/hvc_console.h:59: error: field ‘kref’ has incomplete type
make[2]: *** [drivers/char/hvc_rtas.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2

this was already fixed by rusty (http://lkml.org/lkml/2008/6/27/21).

--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi Andrew,

2.6.26-rc8-mm1 kernel build fails on the x86

CC arch/x86/kernel/paravirt.o
arch/x86/kernel/paravirt.c:383: error: ‘__ptep_modify_prot_start’ undeclared here (not in a function)
make[1]: *** [arch/x86/kernel/paravirt.o] Error 1
make: *** [arch/x86/kernel] Error 2

linux-next patches has the changes to the adds the function
__ptep_modify_prot_start as inline, the patch s390-build-fixes.patch
is coverting it into macro. Reverting the s390-build-fixes.patch
fixes the build failure.

--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 3 Jul 2008, Jeff Garzik wrote:
> KOSAKI Motohiro wrote:
> > Hi Michael,
> >
> > my server output following error message on 2.6.26-rc8-mm1.
> > Is this a bug?
> >
> > ------------------------------------------------------------------
> > tg3.c:v3.93 (May 22, 2008)
> > GSI 72 (level, low) -> CPU 0 (0x0001) vector 51
> > tg3 0000:06:01.0: PCI INT A -> GSI 72 (level, low) -> IRQ 51
> > firmware: requesting tigon/tg3_tso.bin
> > tg3: Failed to load firmware "tigon/tg3_tso.bin"
> > tg3 0000:06:01.0: PCI INT A disabled
> > GSI 72 (level, low) -> CPU 0 (0x0001) vector 51 unregistered
> > tg3: probe of 0000:06:01.0 failed with error -2
> > GSI 73 (level, low) -> CPU 0 (0x0001) vector 51
> > tg3 0000:06:01.1: PCI INT B -> GSI 73 (level, low) -> IRQ 52
> > firmware: requesting tigon/tg3_tso.bin
>
> This change did not come from the network developers or Broadcom, so someone
> else broke tg3 in -mm...

I think it's a consequence of not choosing CONFIG_FIRMWARE_IN_KERNEL=y.

That caught me out on PowerMac G5 trying mmotm yesterday, it just hung
for a few minutes in earlyish boot with a message about tg3_tso.bin,
and then proceeded to boot up but without the network. I was unclear
whether I'd been stupid, or the FIRMWARE_IN_KERNEL Kconfigery was poor.

I avoid initrd, and have tigon3 built in, if that's of any relevance.

I wonder if that's Andrew's problem with 2.6.26-rc8-mm1 on his G5:
mine here boots up fine (now I know to CONFIG_FIRMWARE_IN_KERNEL=y).

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hugh Dickins wrote:
> On Thu, 3 Jul 2008, Jeff Garzik wrote:
>> KOSAKI Motohiro wrote:
>>> Hi Michael,
>>>
>>> my server output following error message on 2.6.26-rc8-mm1.
>>> Is this a bug?
>>>
>>> ------------------------------------------------------------------
>>> tg3.c:v3.93 (May 22, 2008)
>>> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51
>>> tg3 0000:06:01.0: PCI INT A -> GSI 72 (level, low) -> IRQ 51
>>> firmware: requesting tigon/tg3_tso.bin
>>> tg3: Failed to load firmware "tigon/tg3_tso.bin"
>>> tg3 0000:06:01.0: PCI INT A disabled
>>> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51 unregistered
>>> tg3: probe of 0000:06:01.0 failed with error -2
>>> GSI 73 (level, low) -> CPU 0 (0x0001) vector 51
>>> tg3 0000:06:01.1: PCI INT B -> GSI 73 (level, low) -> IRQ 52
>>> firmware: requesting tigon/tg3_tso.bin
>> This change did not come from the network developers or Broadcom, so someone
>> else broke tg3 in -mm...
>
> I think it's a consequence of not choosing CONFIG_FIRMWARE_IN_KERNEL=y.
>
> That caught me out on PowerMac G5 trying mmotm yesterday, it just hung
> for a few minutes in earlyish boot with a message about tg3_tso.bin,
> and then proceeded to boot up but without the network. I was unclear
> whether I'd been stupid, or the FIRMWARE_IN_KERNEL Kconfigery was poor.
>
> I avoid initrd, and have tigon3 built in, if that's of any relevance.
>
> I wonder if that's Andrew's problem with 2.6.26-rc8-mm1 on his G5:
> mine here boots up fine (now I know to CONFIG_FIRMWARE_IN_KERNEL=y).


dwmw2 has been told repeatedly that his changes will cause PRECISELY
these problems, but he refuses to take the simple steps necessary to
ensure people can continue to boot their kernels after his changes go in.

Presently his tg3 changes have been nak'd, in part, because of this
obviously, forseeable, work-around-able breakage.

Jeff


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 2008-07-03 at 09:11 -0400, Jeff Garzik wrote:
> Hugh Dickins wrote:
> > On Thu, 3 Jul 2008, Jeff Garzik wrote:
> >> KOSAKI Motohiro wrote:
> >>> Hi Michael,
> >>>
> >>> my server output following error message on 2.6.26-rc8-mm1.
> >>> Is this a bug?
> >>>
> >>> ------------------------------------------------------------------
> >>> tg3.c:v3.93 (May 22, 2008)
> >>> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51
> >>> tg3 0000:06:01.0: PCI INT A -> GSI 72 (level, low) -> IRQ 51
> >>> firmware: requesting tigon/tg3_tso.bin
> >>> tg3: Failed to load firmware "tigon/tg3_tso.bin"
> >>> tg3 0000:06:01.0: PCI INT A disabled
> >>> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51 unregistered
> >>> tg3: probe of 0000:06:01.0 failed with error -2
> >>> GSI 73 (level, low) -> CPU 0 (0x0001) vector 51
> >>> tg3 0000:06:01.1: PCI INT B -> GSI 73 (level, low) -> IRQ 52
> >>> firmware: requesting tigon/tg3_tso.bin
> >> This change did not come from the network developers or Broadcom, so someone
> >> else broke tg3 in -mm...
> >
> > I think it's a consequence of not choosing CONFIG_FIRMWARE_IN_KERNEL=y.
> >
> > That caught me out on PowerMac G5 trying mmotm yesterday, it just hung
> > for a few minutes in earlyish boot with a message about tg3_tso.bin,
> > and then proceeded to boot up but without the network. I was unclear
> > whether I'd been stupid, or the FIRMWARE_IN_KERNEL Kconfigery was poor.

I shall respectfully refrain from commenting on the likelihood of the
former. With regard to the latter, here is the help text for the
FIRMWARE_IN_KERNEL option:

help
The kernel source tree includes a number of firmware 'blobs'
which are used by various drivers. The recommended way to
use these is to run "make firmware_install" and to copy the
resulting binary files created in usr/lib/firmware directory
of the kernel tree to the /lib/firmware on your system so
that they can be loaded by userspace helpers on request.

Enabling this option will build each required firmware blob
into the kernel directly, where request_firmware() will find
them without having to call out to userspace. This may be
useful if your root file system requires a device which uses
such firmware, and do not wish to use an initrd.

This single option controls the inclusion of firmware for
every driver which usees request_firmare() and ships its
firmware in the kernel source tree, to avoid a proliferation
of 'Include firmware for xxx device' options.

Say 'N' and let firmware be loaded from userspace.

If you think you can improve it, please let me have a revised attempt.

> > I avoid initrd, and have tigon3 built in, if that's of any relevance.
> >
> > I wonder if that's Andrew's problem with 2.6.26-rc8-mm1 on his G5:
> > mine here boots up fine (now I know to CONFIG_FIRMWARE_IN_KERNEL=y).
>
>
> dwmw2 has been told repeatedly that his changes will cause PRECISELY
> these problems, but he refuses to take the simple steps necessary to
> ensure people can continue to boot their kernels after his changes go in.

Complete nonsense. Setting CONFIG_FIRMWARE_IN_KERNEL isn't hard. But
shouldn't be the _default_, either.

> Presently his tg3 changes have been nak'd, in part, because of this
> obviously, forseeable, work-around-able breakage.

They haven't even been reviewed. Nobody seems to have actually looked at
the real changes (in particular, and commented on whether the device can
run anyway without the TSO firmware being loaded, as some people seem to
report). You're just throwing your toys out of the pram because of the
'default n' on a patch about 30 commits earlier in my tree.

--
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse wrote:
>> dwmw2 has been told repeatedly that his changes will cause PRECISELY
>> these problems, but he refuses to take the simple steps necessary to
>> ensure people can continue to boot their kernels after his changes go in.
>
> Complete nonsense. Setting CONFIG_FIRMWARE_IN_KERNEL isn't hard. But
> shouldn't be the _default_, either.
>
>> Presently his tg3 changes have been nak'd, in part, because of this
>> obviously, forseeable, work-around-able breakage.
>
> They haven't even been reviewed. Nobody seems to have actually looked at


Yes, they have. You just didn't like the answers you received.

In particular, the Kconfig default for built-in tg3 firmware should
result in the current behavior, without the user having to take extra steps.

Because of your stubborn refusal on this Kconfig defaults issue, WE
ALREADY HAVE DRIVER-DOES-NOT-WORK BREAKAGE, JUST AS PREDICTED.

Wake up and smell reality. Please.

Jeff


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 2008-07-03 at 09:38 -0400, Jeff Garzik wrote:
> David Woodhouse wrote:
> >> dwmw2 has been told repeatedly that his changes will cause PRECISELY
> >> these problems, but he refuses to take the simple steps necessary to
> >> ensure people can continue to boot their kernels after his changes go in.
> >
> > Complete nonsense. Setting CONFIG_FIRMWARE_IN_KERNEL isn't hard. But
> > shouldn't be the _default_, either.
> >
> >> Presently his tg3 changes have been nak'd, in part, because of this
> >> obviously, forseeable, work-around-able breakage.
> >
> > They haven't even been reviewed. Nobody seems to have actually looked at
>
>
> Yes, they have. You just didn't like the answers you received.

I received no comment on any part of the changes within tg3.c; only
whining about the default behaviour -- which isn't even _set_ as part of
the patch in question, any more.

> In particular, the Kconfig default for built-in tg3 firmware should
> result in the current behavior, without the user having to take extra steps.

After feedback from a number of people, there is no individual Kconfig
option for the various firmwares; there is only one which controls them
all -- CONFIG_FIRMWARE_IN_KERNEL. The thing you're whining about isn't
even part of the patch which needs review.

> Because of your stubborn refusal on this Kconfig defaults issue, WE
> ALREADY HAVE DRIVER-DOES-NOT-WORK BREAKAGE, JUST AS PREDICTED.

I strongly disagree that CONFIG_FIRMWARE_IN_KERNEL=y should be the
default. But if I add this patch elsewhere in the kernel, will you quit
your whining and actually review the patch you were asked to review? ...

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 339c148..d47482f 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -37,6 +37,7 @@ config FW_LOADER
config FIRMWARE_IN_KERNEL
bool "Include in-kernel firmware blobs in kernel binary"
depends on FW_LOADER
+ default y
help
The kernel source tree includes a number of firmware 'blobs'
which are used by various drivers. The recommended way to

--
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andrew Morton napsal(a):
> ftp://ftp.kernel.org/pub/linux/kerne....6.26-rc8-mm1/

Running this in qemu shows up these 3 warnings while booting (It's tainted
due to previous MTRR warning which was there for ever):

PCI: Using configuration type 1 for base access
------------[ cut here ]------------
WARNING: at /home/latest/xxx/drivers/acpi/utilities/utmisc.c:1043
acpi_ut_exception+0x3c/0xb9()
Modules linked in:
Pid: 1, comm: swapper Tainted: G AW 2.6.26-rc8-mm1-nohz #7

Call Trace:
[] warn_on_slowpath+0x5f/0x90
[] ? acpi_ns_evaluate+0x39/0x1c4
[] ? acpi_evaluate_object+0x1ea/0x1fe
[] ? ec_parse_io_ports+0x0/0x34
[] ? acpi_ut_remove_reference+0x2d/0x31
[] ? acpi_ns_search_one_scope+0x1d/0x46
[] ? acpi_ns_search_and_enter+0xbc/0x18a
[] acpi_ut_exception+0x3c/0xb9
[] ? _spin_unlock_irqrestore+0x30/0x40
[] ? up+0x34/0x50
[] ? _spin_unlock_irqrestore+0x30/0x40
[] ? down_timeout+0x3c/0x60
[] ? _spin_unlock_irqrestore+0x30/0x40
[] ? up+0x34/0x50
[] ? acpi_ec_gpe_handler+0x0/0x109
[] acpi_install_gpe_handler+0x12c/0x13a
[] ? acpi_init+0x0/0x221
[] ec_install_handlers+0x2e/0x9c
[] acpi_ec_ecdt_probe+0xee/0x124
[] acpi_init+0x85/0x221
[] ? kset_create_and_add+0x6b/0xa0
[] ? pci_slot_init+0x0/0x50
[] do_one_initcall+0x35/0x15d
[] ? register_irq_proc+0xe8/0x110
[] ? __inode_dir_notify+0x30/0xf0
[] kernel_init+0x19b/0x1a6
[] ? schedule_tail+0x27/0x60
[] child_rip+0xa/0x12
[] ? kernel_init+0x0/0x1a6
[] ? child_rip+0x0/0x12

---[ end trace 4eaa2a86a8e2da22 ]---
ACPI Exception (evxface-0645): AE_BAD_PARAMETER, Installing notify handler
failed [20080609]
ACPI: Interpreter enabled







ACPI: EC: driver started in poll mode
------------[ cut here ]------------
WARNING: at /home/latest/xxx/drivers/acpi/utilities/utmisc.c:1043
acpi_ut_exception+0x3c/0xb9()
Modules linked in:
Pid: 1, comm: swapper Tainted: G AW 2.6.26-rc8-mm1-nohz #7

Call Trace:
[] warn_on_slowpath+0x5f/0x90
[] ? __const_udelay+0x43/0x50
[] ? __call_console_drivers+0x6e/0x90
[] ? up+0x34/0x50
[] ? release_console_sem+0x1e4/0x1f0
[] acpi_ut_exception+0x3c/0xb9
[] ? idr_get_empty_slot+0x102/0x2b0
[] ? down_timeout+0x3c/0x60
[] ? down_timeout+0x3c/0x60
[] ? up+0x34/0x50
[] ? acpi_ec_gpe_handler+0x0/0x109
[] acpi_install_gpe_handler+0x12c/0x13a
[] ec_install_handlers+0x2e/0x9c
[] acpi_ec_start+0x20/0x44
[] acpi_start_single_object+0x2a/0x54
[] acpi_device_probe+0x78/0x8c
[] driver_probe_device+0xa2/0x1e0
[] __driver_attach+0x8b/0x90
[] ? __driver_attach+0x0/0x90
[] bus_for_each_dev+0x6b/0xa0
[] ? kobject_get+0x1a/0x30
[] driver_attach+0x1c/0x20
[] bus_add_driver+0x208/0x280
[] ? acpi_ec_init+0x0/0x61
[] driver_register+0x70/0x160
[] ? acpi_ec_init+0x0/0x61
[] acpi_bus_register_driver+0x3e/0x40
[] acpi_ec_init+0x3f/0x61
[] do_one_initcall+0x35/0x15d
[] ? register_irq_proc+0xe8/0x110
[] ? __inode_dir_notify+0x30/0xf0
[] kernel_init+0x19b/0x1a6
[] ? schedule_tail+0x27/0x60
[] child_rip+0xa/0x12
[] ? kernel_init+0x0/0x1a6
[] ? child_rip+0x0/0x12

---[ end trace 4eaa2a86a8e2da22 ]---
ACPI Exception (evxface-0645): AE_BAD_PARAMETER, Installing notify handler
failed [20080609]
ACPI: PCI Root Bridge [PCI0] (0000:00)









processor ACPI0007:00: registered as cooling_device0
------------[ cut here ]------------
WARNING: at /home/latest/xxx/drivers/acpi/utilities/utmisc.c:1043
acpi_ut_exception+0x3c/0xb9()
Modules linked in:
Pid: 1, comm: swapper Tainted: G AW 2.6.26-rc8-mm1-nohz #7

Call Trace:
[] warn_on_slowpath+0x5f/0x90
[] ? up+0x34/0x50
[] ? acpi_os_release_object+0x9/0xd
[] ? acpi_ut_delete_object_desc+0x48/0x4c
[] ? acpi_ut_delete_internal_obj+0x167/0x16f
[] ? acpi_ut_update_ref_count+0x57/0xa3
[] ? acpi_ut_update_object_reference+0xf7/0x153
[] acpi_ut_exception+0x3c/0xb9
[] ? acpi_os_signal_semaphore+0x23/0x27
[] ? acpi_evaluate_object+0x1ea/0x1fe
[] ? acpi_ut_delete_internal_obj+0x167/0x16f
[] ? acpi_evaluate_integer+0xbf/0xd1
[] acpi_thermal_trips_update+0x6a/0x56c
[] ? acpi_evaluate_object+0x1ea/0x1fe
[] ? sysfs_ilookup_test+0x0/0x20
[] ? _spin_unlock+0x2e/0x40
[] ? acpi_evaluate_integer+0xbf/0xd1
[] acpi_thermal_add+0x3cf/0x43e
[] acpi_device_probe+0x49/0x8c
[] driver_probe_device+0xa2/0x1e0
[] __driver_attach+0x8b/0x90
[] ? __driver_attach+0x0/0x90
[] bus_for_each_dev+0x6b/0xa0
[] ? kobject_get+0x1a/0x30
[] driver_attach+0x1c/0x20
[] bus_add_driver+0x208/0x280
[] ? acpi_thermal_init+0x0/0x83
[] driver_register+0x70/0x160
[] ? acpi_thermal_init+0x0/0x83
[] acpi_bus_register_driver+0x3e/0x40
[] acpi_thermal_init+0x61/0x83
[] do_one_initcall+0x35/0x15d
[] ? register_irq_proc+0xe8/0x110
[] ? __inode_dir_notify+0x30/0xf0
[] kernel_init+0x19b/0x1a6
[] ? schedule_tail+0x27/0x60
[] child_rip+0xa/0x12
[] ? kernel_init+0x0/0x1a6
[] ? child_rip+0x0/0x12

---[ end trace 4eaa2a86a8e2da22 ]---
ACPI Exception (thermal-0377): AE_OK, No or invalid critical threshold
[20080609]
Real Time Clock Driver v1.12ac

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jiri Slaby wrote:
> Andrew Morton napsal(a):
>> ftp://ftp.kernel.org/pub/linux/kerne....6.26-rc8-mm1/
>>
>
> Running this in qemu shows up these 3 warnings while booting (It's
> tainted due to previous MTRR warning which was there for ever):
>
> PCI: Using configuration type 1 for base access
> ------------[ cut here ]------------
> WARNING: at /home/latest/xxx/drivers/acpi/utilities/utmisc.c:1043

Not sure where that is coming from. My tree and my copy of linux-next
doesn't have a WARN_ON in this function.

Anyways, I assume you always saw this message right?

> ACPI Exception (evxface-0645): AE_BAD_PARAMETER, Installing notify
> handler failed [20080609]
> ACPI: Interpreter enabled

And the only thing new is the backtrace right?

Similar with the other messages. If you ignore the backtraces
is there any difference?

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andi Kleen napsal(a):
> Jiri Slaby wrote:
>> Andrew Morton napsal(a):
>>> ftp://ftp.kernel.org/pub/linux/kerne....6.26-rc8-mm1/
>>>
>>
>> Running this in qemu shows up these 3 warnings while booting (It's
>> tainted due to previous MTRR warning which was there for ever):
>>
>> PCI: Using configuration type 1 for base access
>> ------------[ cut here ]------------
>> WARNING: at /home/latest/xxx/drivers/acpi/utilities/utmisc.c:1043
>
> Not sure where that is coming from. My tree and my copy of linux-next
> doesn't have a WARN_ON in this function.

It's from
acpi-utmisc-use-warn_on-instead-of-warn_on_slowpath.patch

> Anyways, I assume you always saw this message right?

Yes (almost, see below), I've checked this now.

>> ACPI Exception (evxface-0645): AE_BAD_PARAMETER, Installing notify
>> handler failed [20080609]
>> ACPI: Interpreter enabled
>
> And the only thing new is the backtrace right?

In the two cases. The thermal one is new:

processor ACPI0007:00: registered as cooling_device0
-thermal LNXTHERM:01: registered as thermal_zone0
-ACPI: Critical trip point
-Critical temperature reached (60 C), shutting down.
-ACPI: Thermal Zone [THRM] (60 C)
+------------[ cut here ]------------
+WARNING: at /home/latest/xxx/drivers/acpi/utilities/utmisc.c:1043
acpi_ut_exception+0x3c/0xb9()
+Modules linked in:
+Pid: 1, comm: swapper Tainted: G AW 2.6.26-rc8-mm1-nohz #9
+
+Call Trace:
+ [] warn_on_slowpath+0x5f/0x90
+ [] ? up+0x34/0x50
+ [] ? acpi_os_release_object+0x9/0xd
+ [] ? acpi_ut_delete_object_desc+0x48/0x4c
+ [] ? acpi_ut_delete_internal_obj+0x167/0x16f
+ [] ? acpi_ut_update_ref_count+0x57/0xa3
+ [] ? acpi_ut_update_object_reference+0xf7/0x153
+ [] acpi_ut_exception+0x3c/0xb9
+ [] ? acpi_os_signal_semaphore+0x23/0x27
+ [] ? acpi_evaluate_object+0x1ea/0x1fe
+ [] ? acpi_ut_delete_internal_obj+0x167/0x16f
+ [] ? acpi_evaluate_integer+0xbf/0xd1
+ [] acpi_thermal_trips_update+0x6a/0x56c
+ [] ? acpi_evaluate_object+0x1ea/0x1fe
+ [] ? sysfs_ilookup_test+0x0/0x20
+ [] ? _spin_unlock+0x2e/0x40
+ [] ? acpi_evaluate_integer+0xbf/0xd1
+ [] acpi_thermal_add+0x3cf/0x43e
+ [] acpi_device_probe+0x49/0x8c
+ [] driver_probe_device+0xa2/0x1e0
+ [] __driver_attach+0x8b/0x90
+ [] ? __driver_attach+0x0/0x90
+ [] bus_for_each_dev+0x6b/0xa0
+ [] ? kobject_get+0x1a/0x30
+ [] driver_attach+0x1c/0x20
+ [] bus_add_driver+0x208/0x280
+ [] ? acpi_thermal_init+0x0/0x83
+ [] driver_register+0x70/0x160
+ [] ? acpi_thermal_init+0x0/0x83
+ [] acpi_bus_register_driver+0x3e/0x40
+ [] acpi_thermal_init+0x61/0x83
+ [] do_one_initcall+0x35/0x15d
+ [] ? register_irq_proc+0xe8/0x110
+ [] ? __inode_dir_notify+0x30/0xf0
+ [] kernel_init+0x19b/0x1a6
+ [] ? schedule_tail+0x27/0x60
+ [] child_rip+0xa/0x12
+ [] ? kernel_init+0x0/0x1a6
+ [] ? child_rip+0x0/0x12
+
+---[ end trace 4eaa2a86a8e2da22 ]---
+ACPI Exception (thermal-0377): AE_OK, No or invalid critical threshold
[20080609]
Real Time Clock Driver v1.12ac
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Jul 3, 2008, at 7:59 AM, KOSAKI Motohiro wrote:
> Hi Michael,
>
> my server output following error message on 2.6.26-rc8-mm1.
> Is this a bug?
>
> ------------------------------------------------------------------
> tg3.c:v3.93 (May 22, 2008)
> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51
> tg3 0000:06:01.0: PCI INT A -> GSI 72 (level, low) -> IRQ 51
> firmware: requesting tigon/tg3_tso.bin
> tg3: Failed to load firmware "tigon/tg3_tso.bin"
> tg3 0000:06:01.0: PCI INT A disabled
> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51 unregistered
> tg3: probe of 0000:06:01.0 failed with error -2
> GSI 73 (level, low) -> CPU 0 (0x0001) vector 51
> tg3 0000:06:01.1: PCI INT B -> GSI 73 (level, low) -> IRQ 52
> firmware: requesting tigon/tg3_tso.bin

Same problem here with linux-next on a Dell Latitude D620.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, Jul 03, 2008 at 02:52:55PM +0100, David Woodhouse wrote:
>
> After feedback from a number of people, there is no individual Kconfig
> option for the various firmwares; there is only one which controls them
> all -- CONFIG_FIRMWARE_IN_KERNEL. The thing you're whining about isn't
> even part of the patch which needs review.
>
> > Because of your stubborn refusal on this Kconfig defaults issue, WE
> > ALREADY HAVE DRIVER-DOES-NOT-WORK BREAKAGE, JUST AS PREDICTED.
>
> I strongly disagree that CONFIG_FIRMWARE_IN_KERNEL=y should be the
> default. But if I add this patch elsewhere in the kernel, will you quit
> your whining and actually review the patch you were asked to review? ...

I don't think it's whining. If your patch introduces changes which
cause people .config to break by default after upgrading to a newer
kernel and doing "make oldconfig" --- then that's a problem with your
patch, and the missing hunk to enable CONFIG_FIRMWARE_IN_KERNEL=y is
critically important.

Linus has ruled this way in the past, when he's gotten screwed by this
sort of issue in the past, and he was justifiably annoyed. We should
treat the users who are willing to test and provide feedback on the
latest kernel.org kernels with the same amount of regard. And if
there are licensing religious fundamentalists who feel strongly about
the firmware issue, then fine, they can change the .config. But the
default should be to avoid users from having broken kernels, and a
number of (quite clueful) users have already demonstrated that without
setting CONFIG_FIRMWARE_IN_KERNEL=y as the default, your patches cause
breakage.

Regards,

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 3 Jul 2008 17:59:43 +0530 Kamalesh Babulal wrote:

> Hi Andrew,
>
> 2.6.26-rc8-mm1 kernel build fails on the x86
>
> CC arch/x86/kernel/paravirt.o
> arch/x86/kernel/paravirt.c:383: error: _____ptep_modify_prot_start___ undeclared here (not in a function)
> make[1]: *** [arch/x86/kernel/paravirt.o] Error 1
> make: *** [arch/x86/kernel] Error 2
>
> linux-next patches has the changes to the adds the function
> __ptep_modify_prot_start as inline, the patch s390-build-fixes.patch
> is coverting it into macro. Reverting the s390-build-fixes.patch
> fixes the build failure.

grump. Who did all this stuff?

I dunno. I'll drop s390-build-fixes.patch, add some ccs and stomp off.


From: Andrew Morton

In file included from include/asm/pgtable.h:1087,
from include/linux/mm.h:39,
from arch/s390/mm/hugetlbpage.c:8:
include/asm-generic/pgtable.h: In function '__ptep_modify_prot_start':
include/asm-generic/pgtable.h:209: error: dereferencing pointer to incomplete type

Cc: Heiko Carstens
Cc: Martin Schwidefsky
Signed-off-by: Andrew Morton
---

include/asm-generic/pgtable.h | 26 +++++++++-----------------
1 file changed, 9 insertions(+), 17 deletions(-)

diff -puN include/asm-generic/pgtable.h~s390-build-fixes include/asm-generic/pgtable.h
--- a/include/asm-generic/pgtable.h~s390-build-fixes
+++ a/include/asm-generic/pgtable.h
@@ -197,17 +197,13 @@ static inline int pmd_none_or_clear_bad(
}
#endif /* CONFIG_MMU */

-static inline pte_t __ptep_modify_prot_start(struct mm_struct *mm,
- unsigned long addr,
- pte_t *ptep)
-{
- /*
- * Get the current pte state, but zero it out to make it
- * non-present, preventing the hardware from asynchronously
- * updating it.
- */
- return ptep_get_and_clear(mm, addr, ptep);
-}
+/*
+ * Get the current pte state, but zero it out to make it
+ * non-present, preventing the hardware from asynchronously
+ * updating it.
+ */
+#define __ptep_modify_prot_start(mm, addr, ptep) \
+ ptep_get_and_clear(mm, addr, ptep)

static inline void __ptep_modify_prot_commit(struct mm_struct *mm,
unsigned long addr,
@@ -235,12 +231,8 @@ static inline void __ptep_modify_prot_co
* queue the update to be done at some later time. The update must be
* actually committed before the pte lock is released, however.
*/
-static inline pte_t ptep_modify_prot_start(struct mm_struct *mm,
- unsigned long addr,
- pte_t *ptep)
-{
- return __ptep_modify_prot_start(mm, addr, ptep);
-}
+#define ptep_modify_prot_start(mm, addr, ptep) \
+ __ptep_modify_prot_start(mm, addr, ptep)

/*
* Commit an update to a pte, leaving any hardware-controlled bits in
_


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andrew Morton wrote:
> On Thu, 3 Jul 2008 17:59:43 +0530 Kamalesh Babulal wrote:
>
>
>> Hi Andrew,
>>
>> 2.6.26-rc8-mm1 kernel build fails on the x86
>>
>> CC arch/x86/kernel/paravirt.o
>> arch/x86/kernel/paravirt.c:383: error: _____ptep_modify_prot_start___ undeclared here (not in a function)
>>

Where did all those _____underlines___ come from?

>> make[1]: *** [arch/x86/kernel/paravirt.o] Error 1
>> make: *** [arch/x86/kernel] Error 2
>>
>> linux-next patches has the changes to the adds the function
>> __ptep_modify_prot_start as inline, the patch s390-build-fixes.patch
>> is coverting it into macro. Reverting the s390-build-fixes.patch
>> fixes the build failure.
>>
>
> grump. Who did all this stuff?
>
> I dunno. I'll drop s390-build-fixes.patch, add some ccs and stomp off.
>
>
> From: Andrew Morton
>
> In file included from include/asm/pgtable.h:1087,
> from include/linux/mm.h:39,
> from arch/s390/mm/hugetlbpage.c:8:
> include/asm-generic/pgtable.h: In function '__ptep_modify_prot_start':
> include/asm-generic/pgtable.h:209: error: dereferencing pointer to incomplete type
>

We can't turn them into macros because we're expecting to be able to
take the address of __ptep_modify_prot_start/commit. What type is not
defined on s390 at that point? Would simply adding an extra include to
arch/s390/mm/hugetlbpage.c fix the problem?

In the worst case we could push __ptep_modify_proc_start/commit out of
line somewhere appropriate, but that's a bit sad given how simple they are.

J

> Cc: Heiko Carstens
> Cc: Martin Schwidefsky
> Signed-off-by: Andrew Morton
> ---
>
> include/asm-generic/pgtable.h | 26 +++++++++-----------------
> 1 file changed, 9 insertions(+), 17 deletions(-)
>
> diff -puN include/asm-generic/pgtable.h~s390-build-fixes include/asm-generic/pgtable.h
> --- a/include/asm-generic/pgtable.h~s390-build-fixes
> +++ a/include/asm-generic/pgtable.h
> @@ -197,17 +197,13 @@ static inline int pmd_none_or_clear_bad(
> }
> #endif /* CONFIG_MMU */
>
> -static inline pte_t __ptep_modify_prot_start(struct mm_struct *mm,
> - unsigned long addr,
> - pte_t *ptep)
> -{
> - /*
> - * Get the current pte state, but zero it out to make it
> - * non-present, preventing the hardware from asynchronously
> - * updating it.
> - */
> - return ptep_get_and_clear(mm, addr, ptep);
> -}
> +/*
> + * Get the current pte state, but zero it out to make it
> + * non-present, preventing the hardware from asynchronously
> + * updating it.
> + */
> +#define __ptep_modify_prot_start(mm, addr, ptep) \
> + ptep_get_and_clear(mm, addr, ptep)
>
> static inline void __ptep_modify_prot_commit(struct mm_struct *mm,
> unsigned long addr,
> @@ -235,12 +231,8 @@ static inline void __ptep_modify_prot_co
> * queue the update to be done at some later time. The update must be
> * actually committed before the pte lock is released, however.
> */
> -static inline pte_t ptep_modify_prot_start(struct mm_struct *mm,
> - unsigned long addr,
> - pte_t *ptep)
> -{
> - return __ptep_modify_prot_start(mm, addr, ptep);
> -}
> +#define ptep_modify_prot_start(mm, addr, ptep) \
> + __ptep_modify_prot_start(mm, addr, ptep)
>
> /*
> * Commit an update to a pte, leaving any hardware-controlled bits in
> _
>
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 03 Jul 2008 11:00:35 -0700 Jeremy Fitzhardinge wrote:

> Andrew Morton wrote:
> > On Thu, 3 Jul 2008 17:59:43 +0530 Kamalesh Babulal wrote:
> >
> >
> >> Hi Andrew,
> >>
> >> 2.6.26-rc8-mm1 kernel build fails on the x86
> >>
> >> CC arch/x86/kernel/paravirt.o
> >> arch/x86/kernel/paravirt.c:383: error: _____ptep_modify_prot_start___ undeclared here (not in a function)
> >>
>
> Where did all those _____underlines___ come from?

gcc idiocy - emitting non-ascii characters from a programming tool.
Their survival rate through downstream handling is about 2%. LANG=C
helps.

> >> make[1]: *** [arch/x86/kernel/paravirt.o] Error 1
> >> make: *** [arch/x86/kernel] Error 2
> >>
> >> linux-next patches has the changes to the adds the function
> >> __ptep_modify_prot_start as inline, the patch s390-build-fixes.patch
> >> is coverting it into macro. Reverting the s390-build-fixes.patch
> >> fixes the build failure.
> >>
> >
> > grump. Who did all this stuff?
> >
> > I dunno. I'll drop s390-build-fixes.patch, add some ccs and stomp off.
> >
> >
> > From: Andrew Morton
> >
> > In file included from include/asm/pgtable.h:1087,
> > from include/linux/mm.h:39,
> > from arch/s390/mm/hugetlbpage.c:8:
> > include/asm-generic/pgtable.h: In function '__ptep_modify_prot_start':
> > include/asm-generic/pgtable.h:209: error: dereferencing pointer to incomplete type
> >
>
> We can't turn them into macros because we're expecting to be able to
> take the address of __ptep_modify_prot_start/commit. What type is not
> defined on s390 at that point? Would simply adding an extra include to
> arch/s390/mm/hugetlbpage.c fix the problem?
>
> In the worst case we could push __ptep_modify_proc_start/commit out of
> line somewhere appropriate, but that's a bit sad given how simple they are.

I think the s390 guys just fixed the original build error.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 2008-07-03 at 13:30 -0400, Theodore Tso wrote:
> I don't think it's whining.

Neither is it an adequate review of the actual patch which was
submitted.

> If your patch introduces changes which
> cause people .config to break by default after upgrading to a newer
> kernel and doing "make oldconfig"

They had to 'make oldconfig' and then actually _choose_ to say 'no' to
an option which is fairly clearly documented, that they are the
relatively unusual position of wanting to have said 'yes' to. You're
getting into Aunt Tillie territory, when you complain about that.

Although it does make me wonder if it was better the way I had it
originally, with individual options like TIGON3_FIRMWARE_IN_KERNEL
attached to each driver, rather than a single FIRMWARE_IN_KERNEL option
which controls them all.

Perhaps one way to help Aunt Tillie would be to tweak Kbuild to look at
the MODULE_FIRMWARE() statements for in-kernel drivers, and to print a
warning when the build finishes: "Your static kernel image may require
the following firmware files, which are not included: ..."

It's wrong to change the CONFIG_FIRMWARE_IN_KERNEL default to 'Y',
because the _normal_ setting for that option _really_ should be 'N'.
Using request_firmware() satisfied from userspace is best practice these
days, and almost all recent drivers do it that way _unconditionally_
anyway.

What we're doing now is just cleaning up the older drivers which don't
use request_firmware(), to conform to what is now common practice. And
while we're retaining the _option_ to continue to build their firmware
into the static kernel image, it isn't recommended and really shouldn't
be the default configuration.

> Linus has ruled this way in the past, when he's gotten screwed by this
> sort of issue in the past, and he was justifiably annoyed.

I am content to let Linus decide on what the default for the
FIRMWARE_IN_KERNEL option will be. I am adamant that it _should_ be 'N',
but it's easy enough for Linus to overrule me with a one-line change.

In the meantime, it would be useful if Jeff would quit throwing his toys
out of the pram on that issue and actually review the _code_ changes. In
particular, are the reports correct that the device operates just fine
without the TSO firmware loaded? Should we change the request_firmware()
error path to just disable TSO and continue with the initialisation?

I can understand why he might not want to answer that if the answer is
affirmative, I suppose -- it detracts even _further_ from his already
rather dubious argument about 'breaking' the driver, if it'll actually
continue to work even when the firmware is completely absent. But it
would be nice to get an honest and straightforward review of the code
from _someone_ who actually knows the hardware.

> And if there are licensing religious fundamentalists who feel
> strongly about the firmware issue, then fine, they can change
> the .config.

Less of the ad hominem, please. Especially when it's so misdirected.

Updating these drivers to remove large blobs of static unswappable data
from the kernel, and having it provided from userspace on demand as
modern Linux drivers do, is a perfectly sensible technical goal all on
its own.

And given the GPL's explicit provisions with regard to collective works
there are also entirely reasonable, non-"fundamentalist" grounds for
believing that it _may_ pose a licensing problem, and for wanting to err
on the side of caution in that respect too.

Fedora is almost certain to ship with CONFIG_FIRMWARE_IN_KERNEL=n, and
I'd be very surprised if Debian and other major distributions don't
follow suit. It is the sensible, pragmatic, technically sound choice.

> But the default should be to avoid users from having broken kernels,
> and a number of (quite clueful) users have already demonstrated that
> without setting CONFIG_FIRMWARE_IN_KERNEL=y as the default, your
> patches cause breakage.

By this argument, shouldn't we include images in the static kernel for
_all_ drivers which currently use request_firmware()? Otherwise, it's
possible for the user to 'break' them, right?

--
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, Jul 03, 2008 at 11:14:18AM -0700, Andrew Morton wrote:
> On Thu, 03 Jul 2008 11:00:35 -0700 Jeremy Fitzhardinge wrote:
> > >> make[1]: *** [arch/x86/kernel/paravirt.o] Error 1
> > >> make: *** [arch/x86/kernel] Error 2
> > >>
> > >> linux-next patches has the changes to the adds the function
> > >> __ptep_modify_prot_start as inline, the patch s390-build-fixes.patch
> > >> is coverting it into macro. Reverting the s390-build-fixes.patch
> > >> fixes the build failure.
> > >>
> > >
> > > grump. Who did all this stuff?
> > >
> > > I dunno. I'll drop s390-build-fixes.patch, add some ccs and stomp off.
> > >
> > >
> > > From: Andrew Morton
> > >
> > > In file included from include/asm/pgtable.h:1087,
> > > from include/linux/mm.h:39,
> > > from arch/s390/mm/hugetlbpage.c:8:
> > > include/asm-generic/pgtable.h: In function '__ptep_modify_prot_start':
> > > include/asm-generic/pgtable.h:209: error: dereferencing pointer to incomplete type
> > >
> >
> > We can't turn them into macros because we're expecting to be able to
> > take the address of __ptep_modify_prot_start/commit. What type is not
> > defined on s390 at that point? Would simply adding an extra include to
> > arch/s390/mm/hugetlbpage.c fix the problem?

We need struct task_struct... I added an include to
asm-s390/pgtable.h and it seems to fix the build problem.
I expected include dependency hell...

> > In the worst case we could push __ptep_modify_proc_start/commit out of
> > line somewhere appropriate, but that's a bit sad given how simple they are.
>
> I think the s390 guys just fixed the original build error.

Not this one, but if it works I'm going to push that to git-s390.
Currently wading through the s390 build bugs in linux-next and trying to
fix them all :/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 03 Jul 2008 19:56:02 BST, David Woodhouse said:

> They had to 'make oldconfig' and then actually _choose_ to say 'no' to
> an option which is fairly clearly documented, that they are the
> relatively unusual position of wanting to have said 'yes' to. You're
> getting into Aunt Tillie territory, when you complain about that.

Note that some of us chose 'no' because we *thought* that we already *had*
everything in /lib/firmware that we needed (in my case, the iwl3945 wireless
firmware and the Intel cpu microcode). The first that I realized that
the tg3 *had* firmware was when I saw the failure message, because before
that, the binary blob was inside the kernel. And then, it wasn't trivially
obvious how to get firmware loaded if the tg3 driver was builtin rather
than a module.

And based on some of the other people who apparently got bit by this same
exact behavior change on this same exact "builtin but no firmware in kernel"
config with this same exact driver, it's obvious that one of two things is true:

1) Several of the highest-up maintainers are Aunt Tillies.
or
2) This is sufficiently subtle and complicated that far more experienced
people than Aunt Tillie will Get It Very Wrong.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFIbSj7cC3lWbTT17ARAgRJAJ9f5OBi6ZMoDDh4l/SOO5rzlbw3dgCg1KRC
0rGxreac3Gnc8oKVstJmfoI=
=CaEO
-----END PGP SIGNATURE-----