lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 30 Jul 2013 12:06:16 +0800
From:	Yijing Wang <wangyijing@...wei.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Don Dutile <ddutile@...hat.com>,
	Paul Bolle <pebolle@...cali.nl>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Rafael <rjw@...k.pl>, Hanjun Guo <guohanjun@...wei.com>,
	Jiang Liu <jiang.liu@...wei.com>,
	Oliver Neukum <oneukum@...e.de>,
	Gu Zheng <guz.fnst@...fujitsu.com>
Subject: Re: [PATCH -v3 3/3] PCI,pciehp: use PCIe DSN to identify device change
 during suspend

>>
>> Hi Bjorn,
>>    I'm reworking this patch, but found some strange info about vpd serial number.
>> I have two x86 machines, they almost have the same hardware topology. But by lspci,
>> I found two different Broadcom BCM5709 NIC in different machine have the same vpd serial
>> number. If this is normal, vpd serial number seems to be useless for identify device change.
> 
> I wouldn't say it's completely useless.  If the VPD serial number
> changes, we can be pretty confident that the card has changed.  It's
> just that if the VPD serial number is unchanged, we might incorrectly
> assume it's the same device.
> 
> But we currently *always* assume it's the same device, since we don't
> look at serial numbers at all.  If we can detect some changes, that
> should be an improvement over what we have today even though it's not
> perfect.

Hmmm, Yes, different VPD serial number must comes from different device.
Although the same serial number maybe not the same device.

I will send out the new version patchset soon.

Thanks!
Yijing.

> 
>> The first machine:
>> linux:/home/yijing # lspci -vvv -s 0000:01:00.0
>> 01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)
>>         Subsystem: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet
>>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>         Latency: 0, Cache Line Size: 256 bytes
>>         Interrupt: pin A routed to IRQ 28
>>         Region 0: Memory at c0000000 (64-bit, non-prefetchable) [size=32M]
>>         Capabilities: [48] Power Management version 3
>>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>                 Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
>>         Capabilities: [50] Vital Product Data
>>                 Product Name: Broadcom NetXtreme II Ethernet Controller
>>                 Read-only fields:
>>                         [PN] Part number: BCM95706A0
>>                         [EC] Engineering changes: 220197-2
>>                         [SN] Serial number: 0123456789
>>                         [MN] Manufacture ID: 31 34 65 34
>>                         [RV] Reserved: checksum good, 31 byte(s) reserved
>>                 End
>>         Capabilities: [58] MSI: Enable- Count=1/16 Maskable- 64bit+
>>                 Address: 0000000000000000  Data: 0000
>>         ..............[snip]...................
>>
>> The second machine:
>> linux-suse-vmdq:~/pciutils-3.2.0 # ./lspci -vvv -s 01:00.0
>> 01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)
>>         Subsystem: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet
>>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>         Latency: 0, Cache Line Size: 256 bytes
>>         Interrupt: pin A routed to IRQ 28
>>         Region 0: Memory at f6000000 (64-bit, non-prefetchable) [size=32M]
>>         Capabilities: [48] Power Management version 3
>>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>                 Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
>>         Capabilities: [50] Vital Product Data
>>                 Product Name: Broadcom NetXtreme II Ethernet Controller
>>                 Read-only fields:
>>                         [PN] Part number: BCM95706A0
>>                         [EC] Engineering changes: 220197-2
>>                         [SN] Serial number: 0123456789
>>                         [MN] Manufacture ID: 31 34 65 34
>>                         [RV] Reserved: checksum good, 31 byte(s) reserved
>>                 End
>>         .......[snip]........
>>
>>
>>>
>>> Also, I think it's possible to use acpiphp for ExpressCard slots, and
>>> this patch doesn't help acpiphp detect card swaps.  I don't see any
>>> mention of suspend/resume in acpiphp, so I don't know if it does
>>> anything at all to detect card changes while suspended.  Maybe Rafael
>>> can shed some light?
>>>
>>> I put the first two patches on a pci/yijing-dsn-v3 branch while we
>>> work out the details of this one.
>>>
>>> Bjorn
>>>
>>>>         } else if (!list_empty(&pbus->devices)) {
>>>>                 pciehp_disable_slot(slot);
>>>>         }
>>>> --
>>>> 1.7.1
>>>>
>>>>
>>>
>>> .
>>>
>>
>>
>> --
>> Thanks!
>> Yijing
>>
> 
> .
> 


-- 
Thanks!
Yijing

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ