| 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
| ||
|
Message-ID: <20071115173613.GG7541@ldl.fc.hp.com>
Date: Thu, 15 Nov 2007 10:36:13 -0700
From: Alex Chiang <achiang@...com>
To: Gary Hade <garyhade@...ibm.com>
Cc: Matthew Wilcox <matthew@....cx>, Greg KH <greg@...ah.com>,
gregkh@...e.de, kristen.c.accardi@...el.com, lenb@...nel.org,
rick.jones2@...com, linux-kernel@...r.kernel.org,
linux-pci@...ey.karlin.mff.cuni.cz,
pcihpd-discuss@...ts.sourceforge.net, linux-acpi@...r.kernel.org
Subject: Re: [PATCH 0/5][RFC] Physical PCI slot objects
Hi Gary,
[I'm gonna take the points in your mail a little out of order]
> No, acpiphp should (and did before your changes) register all
> hotplug capable slots. All 6 slots (2 PCI-X, 4 PCIe) in that
> system are hotplug capable. Emptyness shouldn't matter. If
> the empty slots are not registered it is not be possible to
> successfully hotplug cards to them.
Of course, you are right. I am not sure what I was thinking when
I wrote that email yesterday, but I pretty much got it exactly
wrong. I think I confused myself between empty/populated vs
hp/non-hp. In any case, thanks for the patient explanation.
I went back and looked at a vanilla kernel on my machine that has
the following hardware configuration:
HP rx6600
Slot 1-2: PCI-X under PCI root bridges
Slot 3-6: PCIe under transparent P2P bridges
Slot 7-10: PCI-X under PCI root bridges
Slot 1: PCI-X, !populated, !hp
Slot 2: PCI-X, populated, !hp
Slot 3: PCIe, populated, hp
Slot 4: PCIe, populated, hp
Slot 5: PCIe, !populated, hp
Slot 6: PCIe, populated, hp
Slot 7: PCI-X, !populated, hp
Slot 8: PCI-X, !populated, hp
Slot 9: PCI-X, !populated, hp
Slot 10: PCI-X, !populated, hp
On a kernel without my changes, we see:
[root@...ola slots]# modprobe acpiphp
[root@...ola slots]# ls
10 3 4 5 6 7 8 9
[root@...ola slots]# for i in * ; do ls $i ; done
adapter address attention latch power
adapter address attention latch power
adapter address attention latch power
adapter address attention latch power
adapter address attention latch power
adapter address attention latch power
adapter address attention latch power
adapter address attention latch power
[root@...ola slots]# for i in * ; do cat $i/address ; done
0000:01:02
0000:8b:00
0000:52:00
0000:c5:00
0000:10:00
0000:0a:01
0000:4a:01
0000:01:01
This confirms that you were right -- we see all the hp slots show
up, even though many of them are non-populated. Also, the correct
hp entries show up, just like you'd expect.
Ok, so all that said, after re-implementing my ACPI-PCI slot
driver, we get all the correct answers, but with the additional
appearance of slots 1 and 2 (which aren't hotpluggable):
[root@...ola slots]# ls
1 10 2 3 4 5 6 7 8 9
[root@...ola slots]# for i in * ; do ls $i ; done
address
adapter address attention latch power
address
adapter address attention latch power
adapter address attention latch power
adapter address attention latch power
adapter address attention latch power
adapter address attention latch power
adapter address attention latch power
adapter address attention latch power
[root@...ola slots]# for i in * ; do cat $i/address ; done
0000:49:01
0000:01:02
0000:49:02
0000:8b:00
0000:52:00
0000:c5:00
0000:10:00
0000:0a:01
0000:4a:01
0000:01:01
Bonus points because all that noise during boot went away too.
Life is much better when you actually copy an algorithm correctly
rather than coming up with some half-assed solution on one's own.
;)
So if you could try out v2 of my patch series when you get access
to your machine back, I'd much appreciate it. I feel a lot better
about it compared to v1.
> > > Have you possibly considered a kernel option as a kinder
> > > and gentler way of introducing the changes?
> >
> > That is a good idea. I will work on that.
>
> Thanks. This will allow everyone to focus on the systems where
> the changes are most beneficial and not waste a bunch of time
> trying to test everywhere.
I will work on this for v3.
Thanks!
/ac
Here is some dmesg and lspci -vt output in case you want to
double-check my work:
ACPI: PCI Root Bridge [L000] (0000:00)
ACPI: PCI Root Bridge [L001] (0000:01)
ACPI: PCI Root Bridge [L002] (0000:0a)
ACPI: PCI Root Bridge [L003] (0000:0f)
ACPI: PCI Root Bridge [L004] (0000:49)
ACPI: PCI Root Bridge [L005] (0000:4a)
ACPI: PCI Root Bridge [L006] (0000:4f)
ACPI: PCI Root Bridge [L007] (0000:c4)
[root@...ola slots]# lspci -vt
-+-[0000:c4]---00.0-[0000:c5-fe]--
+-[0000:4f]---00.0-[0000:50-c3]----00.0-[0000:51-c3]--+-00.0-[0000:52-8a]----00.0 Hewlett-Packard Company Smart Array Controller
| \-01.0-[0000:8b-c3]----00.0 Hewlett-Packard Company Smart Array Controller
+-[0000:49]-+-02.0 Intel Corporation 82546GB Gigabit Ethernet Controller
| \-02.1 Intel Corporation 82546GB Gigabit Ethernet Controller
+-[0000:0f]---00.0-[0000:10-48]----00.0 Hewlett-Packard Company Smart Array Controller
\-[0000:00]-+-01.0 Hewlett-Packard Company RMP-3 (Remote Management Processor)
+-01.1 Hewlett-Packard Company RMP-3 Shared Memory Driver
+-01.2 Hewlett-Packard Company Diva Serial [GSP] Multiport UART
+-02.0 NEC Corporation USB
+-02.1 NEC Corporation USB
+-02.2 NEC Corporation USB 2.0
\-04.0 ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]
-
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