* Re: [GIT PULL] ibft fix for 3.2-rc6 [not found] ` <CAE9FiQWufpJ7LwNiBnpS9bR_Sk4e5=wNZp2NmKp117+i56h=Sg@mail.gmail.com> @ 2011-12-17 0:40 ` Yinghai Lu 2011-12-17 14:42 ` Konrad Rzeszutek Wilk 2011-12-22 20:58 ` Greg KH 0 siblings, 2 replies; 6+ messages in thread From: Yinghai Lu @ 2011-12-17 0:40 UTC (permalink / raw) To: Greg KH, stable; +Cc: Konrad Rzeszutek Wilk, linux-kernel, pjones [-- Attachment #1: Type: text/plain, Size: 730 bytes --] On Thu, Dec 15, 2011 at 4:37 PM, Yinghai Lu <yinghai@kernel.org> wrote: > On Thu, Dec 15, 2011 at 4:07 PM, Greg KH <gregkh@suse.de> wrote: > >> The patch as-is does not apply to 2.6.32, so I can't apply it there. If >> you want it applied there, please provide the backport to the above >> mentioned email address. please check back ported patch for 2.6.36 to 2.6.39 We don't need to this one for 2.6.32, because EFI/ACPI ibft detecting is only added from 2.6.36. but 2.6.32 base kernel still could take iscsi_ibft.c related changes in the patch, and ignore conflicts with iscs_ibft_find.c. but that will add new feature to 2.6.32. Not sure if stable tree should take that kind of change. Thanks Yinghai [-- Attachment #2: fix_ibft_checking_2.6.39.patch --] [-- Type: text/x-patch, Size: 4005 bytes --] [PATCH -stable] ibft: Fix finding IBFT ACPI table on UEFI commit 935a9fee51c945b8942be2d7b4bae069167b4886 upstream. it is backporting for: kernel 2.6.36, 2.6.37, 2.6.38, 2.6.39 Found one system with UEFI/iBFT, kernel does not detect the iBFT during iscsi_ibft module loading. Root cause: on x86 (UEFI), we are calling of find_ibft_region() much earlier - specifically in setup_arch() before ACPI is enabled. Try to split acpi checking code out and call that later At that time ACPI iBFT already get permanent mapped with ioremap. So isa_virt_to_bus() will get wrong phys from right virt address. We could just skip that phys address printing. For legacy one, print the found address early. -v2: update comments and description according to Konrad. -v3: fix problem about module use case that is found by Konrad. -v4: use acpi_get_table() instead of acpi_table_parse() to handle module use case that is found by Konrad again.. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/firmware/iscsi_ibft.c | 42 +++++++++++++++++++++++++++++++++++-- drivers/firmware/iscsi_ibft_find.c | 22 +------------------ 2 files changed, 42 insertions(+), 22 deletions(-) Index: linux-2.6/drivers/firmware/iscsi_ibft.c =================================================================== --- linux-2.6.orig/drivers/firmware/iscsi_ibft.c +++ linux-2.6/drivers/firmware/iscsi_ibft.c @@ -738,6 +738,37 @@ static void __exit ibft_exit(void) ibft_cleanup(); } +#ifdef CONFIG_ACPI +static const struct { + char *sign; +} ibft_signs[] = { + /* + * One spec says "IBFT", the other says "iBFT". We have to check + * for both. + */ + { ACPI_SIG_IBFT }, + { "iBFT" }, +}; + +static void __init acpi_find_ibft_region(void) +{ + int i; + struct acpi_table_header *table = NULL; + + if (acpi_disabled) + return; + + for (i = 0; i < ARRAY_SIZE(ibft_signs) && !ibft_addr; i++) { + acpi_get_table(ibft_signs[i].sign, 0, &table); + ibft_addr = (struct acpi_table_ibft *)table; + } +} +#else +static void __init acpi_find_ibft_region(void) +{ +} +#endif + /* * ibft_init() - creates sysfs tree entries for the iBFT data. */ @@ -745,9 +776,16 @@ static int __init ibft_init(void) { int rc = 0; + /* + As on UEFI systems the setup_arch()/find_ibft_region() + is called before ACPI tables are parsed and it only does + legacy finding. + */ + if (!ibft_addr) + acpi_find_ibft_region(); + if (ibft_addr) { - printk(KERN_INFO "iBFT detected at 0x%llx.\n", - (u64)isa_virt_to_bus(ibft_addr)); + pr_info("iBFT detected.\n"); rc = ibft_check_device(); if (rc) Index: linux-2.6/drivers/firmware/iscsi_ibft_find.c =================================================================== --- linux-2.6.orig/drivers/firmware/iscsi_ibft_find.c +++ linux-2.6/drivers/firmware/iscsi_ibft_find.c @@ -49,14 +49,6 @@ EXPORT_SYMBOL_GPL(ibft_addr); #define VGA_MEM 0xA0000 /* VGA buffer */ #define VGA_SIZE 0x20000 /* 128kB */ -#ifdef CONFIG_ACPI -static int __init acpi_find_ibft(struct acpi_table_header *header) -{ - ibft_addr = (struct acpi_table_ibft *)header; - return 0; -} -#endif /* CONFIG_ACPI */ - static int __init find_ibft_in_mem(void) { unsigned long pos; @@ -77,6 +69,7 @@ static int __init find_ibft_in_mem(void) * the table cannot be valid. */ if (pos + len <= (IBFT_END-1)) { ibft_addr = (struct acpi_table_ibft *)virt; + pr_info("iBFT found at 0x%lx.\n", pos); break; } } @@ -92,21 +85,10 @@ unsigned long __init find_ibft_region(un ibft_addr = NULL; -#ifdef CONFIG_ACPI - /* - * One spec says "IBFT", the other says "iBFT". We have to check - * for both. - */ - if (!ibft_addr) - acpi_table_parse(ACPI_SIG_IBFT, acpi_find_ibft); - if (!ibft_addr) - acpi_table_parse(IBFT_SIGN, acpi_find_ibft); -#endif /* CONFIG_ACPI */ - /* iBFT 1.03 section 1.4.3.1 mandates that UEFI machines will * only use ACPI for this */ - if (!ibft_addr && !efi_enabled) + if (!efi_enabled) find_ibft_in_mem(); if (ibft_addr) { ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] ibft fix for 3.2-rc6 2011-12-17 0:40 ` [GIT PULL] ibft fix for 3.2-rc6 Yinghai Lu @ 2011-12-17 14:42 ` Konrad Rzeszutek Wilk 2011-12-23 0:45 ` Yinghai Lu 2011-12-22 20:58 ` Greg KH 1 sibling, 1 reply; 6+ messages in thread From: Konrad Rzeszutek Wilk @ 2011-12-17 14:42 UTC (permalink / raw) To: Yinghai Lu; +Cc: Greg KH, stable, linux-kernel, pjones On Fri, Dec 16, 2011 at 04:40:34PM -0800, Yinghai Lu wrote: > On Thu, Dec 15, 2011 at 4:37 PM, Yinghai Lu <yinghai@kernel.org> wrote: > > On Thu, Dec 15, 2011 at 4:07 PM, Greg KH <gregkh@suse.de> wrote: > > > >> The patch as-is does not apply to 2.6.32, so I can't apply it there. �If > >> you want it applied there, please provide the backport to the above > >> mentioned email address. > > please check back ported patch for 2.6.36 to 2.6.39 > > We don't need to this one for 2.6.32, because EFI/ACPI ibft detecting > is only added from 2.6.36. Then 2.6.36 and above should have the fix below. Thanks for porting it over. > > but 2.6.32 base kernel still could take iscsi_ibft.c related changes > in the patch, and ignore conflicts with iscs_ibft_find.c. > but that will add new feature to 2.6.32. Not sure if stable tree > should take that kind of change. It could, but I am not too thrilled about it. > > Thanks > > Yinghai > [PATCH -stable] ibft: Fix finding IBFT ACPI table on UEFI > > commit 935a9fee51c945b8942be2d7b4bae069167b4886 upstream. > > it is backporting for: > kernel 2.6.36, 2.6.37, 2.6.38, 2.6.39 > > Found one system with UEFI/iBFT, kernel does not detect the iBFT during > iscsi_ibft module loading. > > Root cause: on x86 (UEFI), we are calling of find_ibft_region() much earlier > - specifically in setup_arch() before ACPI is enabled. > > Try to split acpi checking code out and call that later > > At that time ACPI iBFT already get permanent mapped with ioremap. > So isa_virt_to_bus() will get wrong phys from right virt address. > We could just skip that phys address printing. > > For legacy one, print the found address early. > > -v2: update comments and description according to Konrad. > -v3: fix problem about module use case that is found by Konrad. > -v4: use acpi_get_table() instead of acpi_table_parse() to handle module use case that is found by Konrad again.. > > Signed-off-by: Yinghai Lu <yinghai@kernel.org> > > --- > drivers/firmware/iscsi_ibft.c | 42 +++++++++++++++++++++++++++++++++++-- > drivers/firmware/iscsi_ibft_find.c | 22 +------------------ > 2 files changed, 42 insertions(+), 22 deletions(-) > > Index: linux-2.6/drivers/firmware/iscsi_ibft.c > =================================================================== > --- linux-2.6.orig/drivers/firmware/iscsi_ibft.c > +++ linux-2.6/drivers/firmware/iscsi_ibft.c > @@ -738,6 +738,37 @@ static void __exit ibft_exit(void) > ibft_cleanup(); > } > > +#ifdef CONFIG_ACPI > +static const struct { > + char *sign; > +} ibft_signs[] = { > + /* > + * One spec says "IBFT", the other says "iBFT". We have to check > + * for both. > + */ > + { ACPI_SIG_IBFT }, > + { "iBFT" }, > +}; > + > +static void __init acpi_find_ibft_region(void) > +{ > + int i; > + struct acpi_table_header *table = NULL; > + > + if (acpi_disabled) > + return; > + > + for (i = 0; i < ARRAY_SIZE(ibft_signs) && !ibft_addr; i++) { > + acpi_get_table(ibft_signs[i].sign, 0, &table); > + ibft_addr = (struct acpi_table_ibft *)table; > + } > +} > +#else > +static void __init acpi_find_ibft_region(void) > +{ > +} > +#endif > + > /* > * ibft_init() - creates sysfs tree entries for the iBFT data. > */ > @@ -745,9 +776,16 @@ static int __init ibft_init(void) > { > int rc = 0; > > + /* > + As on UEFI systems the setup_arch()/find_ibft_region() > + is called before ACPI tables are parsed and it only does > + legacy finding. > + */ > + if (!ibft_addr) > + acpi_find_ibft_region(); > + > if (ibft_addr) { > - printk(KERN_INFO "iBFT detected at 0x%llx.\n", > - (u64)isa_virt_to_bus(ibft_addr)); > + pr_info("iBFT detected.\n"); > > rc = ibft_check_device(); > if (rc) > Index: linux-2.6/drivers/firmware/iscsi_ibft_find.c > =================================================================== > --- linux-2.6.orig/drivers/firmware/iscsi_ibft_find.c > +++ linux-2.6/drivers/firmware/iscsi_ibft_find.c > @@ -49,14 +49,6 @@ EXPORT_SYMBOL_GPL(ibft_addr); > #define VGA_MEM 0xA0000 /* VGA buffer */ > #define VGA_SIZE 0x20000 /* 128kB */ > > -#ifdef CONFIG_ACPI > -static int __init acpi_find_ibft(struct acpi_table_header *header) > -{ > - ibft_addr = (struct acpi_table_ibft *)header; > - return 0; > -} > -#endif /* CONFIG_ACPI */ > - > static int __init find_ibft_in_mem(void) > { > unsigned long pos; > @@ -77,6 +69,7 @@ static int __init find_ibft_in_mem(void) > * the table cannot be valid. */ > if (pos + len <= (IBFT_END-1)) { > ibft_addr = (struct acpi_table_ibft *)virt; > + pr_info("iBFT found at 0x%lx.\n", pos); > break; > } > } > @@ -92,21 +85,10 @@ unsigned long __init find_ibft_region(un > > ibft_addr = NULL; > > -#ifdef CONFIG_ACPI > - /* > - * One spec says "IBFT", the other says "iBFT". We have to check > - * for both. > - */ > - if (!ibft_addr) > - acpi_table_parse(ACPI_SIG_IBFT, acpi_find_ibft); > - if (!ibft_addr) > - acpi_table_parse(IBFT_SIGN, acpi_find_ibft); > -#endif /* CONFIG_ACPI */ > - > /* iBFT 1.03 section 1.4.3.1 mandates that UEFI machines will > * only use ACPI for this */ > > - if (!ibft_addr && !efi_enabled) > + if (!efi_enabled) > find_ibft_in_mem(); > > if (ibft_addr) { ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] ibft fix for 3.2-rc6 2011-12-17 14:42 ` Konrad Rzeszutek Wilk @ 2011-12-23 0:45 ` Yinghai Lu 2011-12-23 3:50 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 6+ messages in thread From: Yinghai Lu @ 2011-12-23 0:45 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: Greg KH, stable, linux-kernel, pjones On Sat, Dec 17, 2011 at 6:42 AM, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote: >> >> but 2.6.32 base kernel still could take iscsi_ibft.c related changes >> in the patch, and ignore conflicts with iscs_ibft_find.c. >> but that will add new feature to 2.6.32. Not sure if stable tree >> should take that kind of change. > > It could, but I am not too thrilled about it. RHEL 6.x are still with 2.6.32... So under UEFI mode installation, users need to input iscsi target info again during selecting storage for installation. Because kernel does not to parse that from acpi iBFT table. When legacy mode iscsi installation is used, installation program will not need user install those info again. QA are complaining that difference. Thanks Yinghai Lu ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] ibft fix for 3.2-rc6 2011-12-23 0:45 ` Yinghai Lu @ 2011-12-23 3:50 ` Konrad Rzeszutek Wilk 2011-12-23 18:24 ` Yinghai Lu 0 siblings, 1 reply; 6+ messages in thread From: Konrad Rzeszutek Wilk @ 2011-12-23 3:50 UTC (permalink / raw) To: Yinghai Lu; +Cc: Greg KH, stable, linux-kernel, pjones >>> but that will add new feature to 2.6.32. Not sure if stable tree >>> should take that kind of change. >> >> It could, but I am not too thrilled about it. > > RHEL 6.x are still with 2.6.32... > If Red Hat needs it, they can back-port it. It is not that hard for it to be done and they are very proficient at it. > So under UEFI mode installation, users need to input iscsi target info > again during selecting storage for installation. Because kernel does > not to parse that from acpi iBFT table. > > When legacy mode iscsi installation is used, installation program will > not need user install those info again. > > QA are complaining that difference. I think I understand your position. You are getting emails from QA testing some hardware saying it does not work with RHEL, so you try upstream, find the bug and fix it (awesome, thanks for doing that), and then you want to back-port the fix so RHEL picks it up (and can close the bug). Thr mechanism for that is by contacting the vendor about this - either using the Program Manager to open a feature request, or waiting for a customer to report this bug (on the Red Hat side) and then your fix will be magically picked up. The stable 2.6.32.x tree would require the sub-maintainer (that is me) to sign off on supporting this in 2.6.32.x tree and I am not signing up for it b/c I don't have the time to support it (this is after-work hours fun stuff I do). ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] ibft fix for 3.2-rc6 2011-12-23 3:50 ` Konrad Rzeszutek Wilk @ 2011-12-23 18:24 ` Yinghai Lu 0 siblings, 0 replies; 6+ messages in thread From: Yinghai Lu @ 2011-12-23 18:24 UTC (permalink / raw) To: konrad; +Cc: Greg KH, stable, linux-kernel, pjones [-- Attachment #1: Type: text/plain, Size: 863 bytes --] On Thu, Dec 22, 2011 at 7:50 PM, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote: >> >> When legacy mode iscsi installation is used, installation program will >> not need user install those info again. >> >> QA are complaining that difference. > > I think I understand your position. You are getting emails from QA > testing some hardware saying it does not work with RHEL, so you try > upstream, find the bug and fix it (awesome, thanks for doing that), > and then you want to back-port the fix so RHEL picks it up (and can > close the bug). Thr mechanism for that is by contacting the vendor > about this - either using the Program Manager to open a feature > request, or waiting for a customer to report this bug (on the Red Hat > side) and then your fix will be magically picked up. yes, attached is the patch for 2.6.32 to close the loop. Thanks Yinghai [-- Attachment #2: fix_ibft_checking_2.6.32.patch --] [-- Type: text/x-patch, Size: 2060 bytes --] [PATCH -v2.6.32] ibft: Finding IBFT ACPI table on UEFI commit 935a9fee51c945b8942be2d7b4bae069167b4886 upstream. Found one system with UEFI/iBFT, kernel does not detect the iBFT during iscsi_ibft module loading. So users will need to input iscsi info during RHEL 6.x installation. We can add checking in ibft_init for acpi. At that time ACPI iBFT already get permanent mapped with ioremap. For legacy one, print the found address early. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/firmware/iscsi_ibft.c | 42 ++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 40 insertions(+), 2 deletions(-) Index: linux-2.6/drivers/firmware/iscsi_ibft.c =================================================================== --- linux-2.6.orig/drivers/firmware/iscsi_ibft.c +++ linux-2.6/drivers/firmware/iscsi_ibft.c @@ -926,6 +926,37 @@ static int __init ibft_register_attribut return rc; } +#ifdef CONFIG_ACPI +static const struct { + char *sign; +} ibft_signs[] = { + /* + * One spec says "IBFT", the other says "iBFT". We have to check + * for both. + */ + { ACPI_SIG_IBFT }, + { "iBFT" }, +}; + +static void __init acpi_find_ibft_region(void) +{ + int i; + struct acpi_table_header *table = NULL; + + if (acpi_disabled) + return; + + for (i = 0; i < ARRAY_SIZE(ibft_signs) && !ibft_addr; i++) { + acpi_get_table(ibft_signs[i].sign, 0, &table); + ibft_addr = (struct acpi_table_ibft *)table; + } +} +#else +static void __init acpi_find_ibft_region(void) +{ +} +#endif + /* * ibft_init() - creates sysfs tree entries for the iBFT data. */ @@ -937,9 +968,16 @@ static int __init ibft_init(void) if (!ibft_kset) return -ENOMEM; + /* + As on UEFI systems the setup_arch()/find_ibft_region() + is called before ACPI tables are parsed and it only does + legacy finding. + */ + if (!ibft_addr) + acpi_find_ibft_region(); + if (ibft_addr) { - printk(KERN_INFO "iBFT detected at 0x%llx.\n", - (u64)isa_virt_to_bus(ibft_addr)); + pr_info("iBFT detected.\n"); rc = ibft_check_device(); if (rc) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] ibft fix for 3.2-rc6 2011-12-17 0:40 ` [GIT PULL] ibft fix for 3.2-rc6 Yinghai Lu 2011-12-17 14:42 ` Konrad Rzeszutek Wilk @ 2011-12-22 20:58 ` Greg KH 1 sibling, 0 replies; 6+ messages in thread From: Greg KH @ 2011-12-22 20:58 UTC (permalink / raw) To: Yinghai Lu; +Cc: Greg KH, stable, Konrad Rzeszutek Wilk, linux-kernel, pjones On Fri, Dec 16, 2011 at 04:40:34PM -0800, Yinghai Lu wrote: > On Thu, Dec 15, 2011 at 4:37 PM, Yinghai Lu <yinghai@kernel.org> wrote: > > On Thu, Dec 15, 2011 at 4:07 PM, Greg KH <gregkh@suse.de> wrote: > > > >> The patch as-is does not apply to 2.6.32, so I can't apply it there. �If > >> you want it applied there, please provide the backport to the above > >> mentioned email address. > > please check back ported patch for 2.6.36 to 2.6.39 Thanks, but I don't think these kernel versions are maintained by anyone anymore, sorry. > We don't need to this one for 2.6.32, because EFI/ACPI ibft detecting > is only added from 2.6.36. > > but 2.6.32 base kernel still could take iscsi_ibft.c related changes > in the patch, and ignore conflicts with iscs_ibft_find.c. > but that will add new feature to 2.6.32. Not sure if stable tree > should take that kind of change. No it will not, sorry. greg k-h ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-12-23 18:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20111215210538.GA12248@konrad-lan>
[not found] ` <CAE9FiQXFgOU3c9Ej-B_sZfhs5sRN87xE93BtZoU2K=M6=_O9YA@mail.gmail.com>
[not found] ` <20111216000716.GA14822@suse.de>
[not found] ` <CAE9FiQWufpJ7LwNiBnpS9bR_Sk4e5=wNZp2NmKp117+i56h=Sg@mail.gmail.com>
2011-12-17 0:40 ` [GIT PULL] ibft fix for 3.2-rc6 Yinghai Lu
2011-12-17 14:42 ` Konrad Rzeszutek Wilk
2011-12-23 0:45 ` Yinghai Lu
2011-12-23 3:50 ` Konrad Rzeszutek Wilk
2011-12-23 18:24 ` Yinghai Lu
2011-12-22 20:58 ` Greg KH
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox