Description of problem:I have listed missing white list symbols for both LSI 3gb/s and 6gb/s drivers. Please include those symbols in next RHEL5.6 release. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Here are list of missing symbols which are not included in RHEL5.5 whitelist symbols for LSI's mpt2sas and mptsas drivers. List for Gen-2 driver (mpt2sas) symbol: pci_request_selected_regions symbol: pci_release_selected_regions symbol: pci_enable_device_mem symbol: pci_select_bars symbol: scsilun_to_int symbol: scsi_build_sense_buffer List for Gen-1 driver (mptsas) symbol: pci_request_selected_regions symbol: pci_release_selected_regions symbol: pci_enable_device_mem symbol: pci_select_bars symbol: mpt_clear_taskmgmt_in_progress_flag symbol: mpt_detach symbol: mpt_suspend symbol: mpt_free_msg_frame symbol: mpt_print_ioc_summary symbol: mpt_raid_phys_disk_pg1 symbol: mpt_GetIocState symbol: mpt_resume symbol: mpt_put_msg_frame symbol: mpt_fwfault_debug symbol: mpt_send_handshake_request symbol: mpt_raid_phys_disk_get_num_paths symbol: mpt_halt_firmware symbol: mpt_get_msg_frame symbol: mpt_HardResetHandler symbol: mpt_set_taskmgmt_in_progress_flag symbol: mpt_deregister symbol: mpt_reset_deregister symbol: mptscsih_host_attrs symbol: mptscsih_qcmd symbol: mptscsih_bios_param symbol: mptscsih_io_done symbol: mptscsih_slave_configure symbol: mpt_config symbol: mptscsih_taskmgmt_complete symbol: mptscsih_ioc_reset symbol: mptscsih_remove symbol: mptscsih_bus_reset symbol: mptscsih_is_phys_disk symbol: mptscsih_proc_info symbol: mptscsih_host_reset symbol: mptbase_sas_persist_operation symbol: mpt_register symbol: mpt_event_deregister symbol: mpt_findImVolumes symbol: mptscsih_taskmgmt_response_code symbol: mptscsih_scandv_complete symbol: mptscsih_resume symbol: mptscsih_raid_id_to_num symbol: mpt_event_register symbol: mpt_raid_phys_disk_pg0 symbol: mptscsih_suspend symbol: mptscsih_slave_destroy symbol: mptscsih_change_queue_depth symbol: mptscsih_dev_reset symbol: mpt_attach symbol: mpt_reset_register symbol: mptscsih_info symbol: mptscsih_abort symbol: mptscsih_get_scsi_lookup symbol: mptscsih_event_process symbol: mptscsih_shutdown symbol: mptscsih_IssueTaskMgmt symbol: mpt_put_msg_frame_hi_pri symbol: mpt_device_driver_deregister symbol: mpt_alloc_fw_memory symbol: mpt_free_fw_memory symbol: mpt_device_driver_register symbol: mpt_verify_adapter symbol: ioc_list Thanks, Kashyap
Kashyap, I'm assuming you would like all of these whitelisted for both the Xen and non-Xen kernels?
(In reply to comment #1) > Kashyap, I'm assuming you would like all of these whitelisted for both the Xen > and non-Xen kernels? Yes, I would rather say all RHEL5.6 flavors. Thanks, Kashyap
I doubt we will whitelist the "mpt" symbols directly, since the idea is that you would simply ship your own version of those if you needed to. The PCI symbols could be added, if that is approved during our internal review. Can you make sure to clarify in this bug what exactly it is you are asking for?
(In reply to comment #3) > I doubt we will whitelist the "mpt" symbols directly, since the idea is that > you would simply ship your own version of those if you needed to. The PCI > symbols could be added, if that is approved during our internal review. Can you > make sure to clarify in this bug what exactly it is you are asking for? jon, I used abi_check.py script against our mptfusion driver. Here is a snippet of output -- #abi_check.py /lib/modules/2.6.18-194.el5xen/kernel/drivers/message/fusion/mptsas.ko Red Hat Enterprise Linux 5 ABI Checker -------------------------------------- ABI Checker version: 1.2 Module: /lib/modules/2.6.18-194.el5xen/kernel/drivers/message/fusion/mptsas.ko Kernel: 2.6.18-164.el5xen Whitelist: /usr/src/kernels/2.6.18-164.el5xen-x86_64/kabi_whitelist WARNING: The following symbols are used by your module WARNING: and are not on the ABI whitelist. symbol: mpt_put_msg_frame_hi_pri symbol: mpt_deregister symbol: mpt_clear_taskmgmt_in_progress_flag symbol: mpt_reset_deregister symbol: mptscsih_host_attrs symbol: mptscsih_qcmd symbol: mptscsih_bios_param symbol: mptscsih_io_done symbol: mptscsih_slave_configure symbol: mpt_config ---- Since output of abi_check.py displayed me above result, I have asked you to include those symbols into the white list. Is there I am missing while doing ABI compatibility test ? Thanks, Kashyap
Thanks for your reply. If you need to use those MPT symbols, it is necessary to include also the other module that provides those symbols, which is part of the MPT set of modules (mptbase, etc). If those are the only missing symbols then this is not a bug and should be closed. Thanks.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
(In reply to comment #4) > WARNING: The following symbols are used by your module > WARNING: and are not on the ABI whitelist. > > symbol: mpt_put_msg_frame_hi_pri > ... > > Since output of abi_check.py displayed me above result, I have asked you to > include those symbols into the white list. > > Is there I am missing while doing ABI compatibility test ? Kashyap, I hope I'm not wrong but the kabi list can be seen as a kind of 'promise' that the symbols in the list will never change. So unless you want that your symbols (mpt....) are used by other modules it makes no sense to froze them in the kabi list. Kabi is meant for symbols from kernel (scsi...) used by your and other modules. This provides then the binary compatibility.
(In reply to comment #8) > (In reply to comment #4) > > > WARNING: The following symbols are used by your module > > WARNING: and are not on the ABI whitelist. > > > > symbol: mpt_put_msg_frame_hi_pri > > ... > > > > Since output of abi_check.py displayed me above result, I have asked you to > > include those symbols into the white list. > > > > Is there I am missing while doing ABI compatibility test ? > > Kashyap, > I hope I'm not wrong but the kabi list can be seen as a kind of 'promise' that > the symbols in the list will never change. So unless you want that your symbols > (mpt....) are used by other modules it makes no sense to froze them in the kabi > list. > Kabi is meant for symbols from kernel (scsi...) used by your and other modules. > This provides then the binary compatibility. Jon and tomas, thanks for your explanation.I may need a small clarification though. * MPT2SAS driver is a single .ko module whereas MPTFUSION is multiple module driver. (mptbase.ko, mptscsih.ko, mptsas.ko...). For MPT2SAS driver, I have not seen any mpt_* symbol in kABI list. As we have run abi_check.py, mptscsih_qcmd(and some other mpt_* symbols) are listed as part of kABI symbol because of it is EXPORTED SYMBOL in mptscsih module, which is only used by same MPTFUSION driver _but_ different module. (mptsas.ko) Thanks, Kashyap
(In reply to comment #5) > Thanks for your reply. If you need to use those MPT symbols, it is necessary to > include also the other module that provides those symbols, which is part of the > MPT set of modules (mptbase, etc). If those are the only missing symbols then YES, I have listed here cumulative list of kABI symbols for all mpt*.ko modules. > this is not a bug and should be closed. Thanks. It means "mpt_* symbols are not a valid candidate for kABI list?" Thanks, Kashyap
(In reply to comment #10) > > this is not a bug and should be closed. Thanks. > It means "mpt_* symbols are not a valid candidate for kABI list?" They can be added technically, but it makes no sense for me.
(In reply to comment #11) > (In reply to comment #10) > > > this is not a bug and should be closed. Thanks. > > It means "mpt_* symbols are not a valid candidate for kABI list?" > > They can be added technically, but it makes no sense for me. Yes, My understanding was also same.! Thanks for clarification. Since we/other customers check kABI compatibility using your "abi_check.py" Which will give wrong information if RHEL does not include those mpt_* symbols. What is your thought on my latest concern ? ~ Kashyap
(In reply to comment #12) > Since we/other customers check kABI compatibility using your "abi_check.py" > Which will give wrong information if RHEL does not include those mpt_* symbols. The abi_check tells you that a symbol is not in our kabi list and nothing more. Being on kabi list is only of benefit if some third party would want use the mpt... symbols, which I think is not expected. With the mpt_ symbols in kabi you would have a kind of 'guarantee' that you can freely switch the binary modules from multiple module driver -> you could then use binary mptbase.ko from 6.0 with mptscsih.ko(6.1.) and mptsas.ko(6.3) in for example version 6.4. The drawback is that you couldn't change the exported(kabi) symbols, so for example you couldn't in mpt_put_msg_frame_hi_pri change the type and amount of arguments. I think you don't want that :)
Indeed, I see, Kashyap, you are saying the script reports any symbols it doesn't know about, regardless? It does indeed, and as Thomas says this isn't a bug. So I think this can be closed as you will provide those symbols through your other driver.
(In reply to comment #13) > (In reply to comment #12) > > Since we/other customers check kABI compatibility using your "abi_check.py" > > Which will give wrong information if RHEL does not include those mpt_* symbols. > > The abi_check tells you that a symbol is not in our kabi list and nothing more. > Being on kabi list is only of benefit if some third party would want use the > mpt... symbols, which I think is not expected. > > With the mpt_ symbols in kabi you would have a kind of 'guarantee' that you can > freely switch the binary modules from multiple module driver -> you could then > use binary mptbase.ko from 6.0 with mptscsih.ko(6.1.) and mptsas.ko(6.3) in for > example version 6.4. > The drawback is that you couldn't change the exported(kabi) symbols, so for > example you couldn't in mpt_put_msg_frame_hi_pri change the type and amount of > arguments. I think you don't want that :) Tomas, I completely agree here. I do understand what you have explained here. Thanks again for making things clearer. Let's don't include those mpt_* symbols in kABI list, but what about generic OS symbols like pci_request_selected_regions, pci_select_bars etc... ~Kashyap
Those symbols (pci_*) are valid requests, but you did not mention them before. Do you mean to say that there are some missing symbols other than the MPT ones? Jon.
(In reply to comment #16) > Those symbols (pci_*) are valid requests, but you did not mention them before. > Do you mean to say that there are some missing symbols other than the MPT ones? > > Jon. Yes, There are some non-mpt_* symbols in list. I have kept them in the same list. If you see my issue description, I have requested for all symbols for kABI inclusion, but after dicussion I agree that mpt_* symbols are not required. Then I thought other than mpt_* symbols, RHEL will include those pci_* symbols. Just to double check I have asked you in my comment #15. Kashyap
Ok. We will review the non-mpt symbols for RHEL5.6.
Created attachment 443427 [details] rhel56-kabi-whitelist-add-pci-symbols.patch
Thank you for filing your request to update our kernel ABI whitelists. We are now reviewing your request and will endeavor to provide an update in due course.
in kernel-2.6.18-223.el5 You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0017.html