Hm, I thought I’d finished making my fall travel plans. Guess not…
SUSE Labs 2008 conference, presenting a version of my PCI slots talk
Thu, Sep 4, 2008 DENVER, CO (DEN) - MUNICH, GFR (MUC) Fri, Sep 5, 2008 MUNICH, GFR (MUC) - PRAGUE, CZECH (PRG)
The return flight home on Sept. 13 is going to be a bit of a bear: PRG-FRA-SFO-RNO.
Even with all this travel, I won’t hit 25K miles, and thus lose my status. Suck.
China’s international profile is somewhere in the upper stratosphere these days, what with the Olympics (acute) and the changing face of the global economy (chronic). The increased exposure is a double-edged sword, of course. Greater outside awareness can bring unwanted scrutiny in addition to the hoped-for enhanced respect.
And that’s all fine and good; nothing is ever a one-way street, and the Chinese government has some serious failures in its current governance policies which ought to be questioned.
But that’s no excuse for why bullshit emails containing such gems as:
Subject: FW: Learn Chinese for the Olympics ENGLISH CHINESE Your body odor is offensive Yu Stin Ki Pu &c.
are circulating around (and happen to land in my inbox). Maybe the alleged humour hits too close to home, but I don’t even understand how something like this is funny. I mean, making fun of the way a language sounds because of your own shortcomings (you don’t understand it, duh) is funny? Really? [Ok, I guess it's also mocking the way that Chinese ESL speakers pronounce English too, so, um, bonus points for attempts at theory of mind humour, but seriously, that ain't even close to the New Yorker.]
Which brings me to an article in Business Pundit entitled 7 Deadly Perceptions About Doing Business with China. The article itself is mildly interesting if you happen to be a business nerd, but there’s an almost throwaway line in there that explains perfectly the racism1 I encounter more often than I would have expected in 2008, A.D.:
Being terrified of a culture, then masking those feelings in a sense of superiority—as Carmosky claims we do with China—isn’t conducive to successful business and economic relations.
My armchair hypothesis? The complete unfamiliarity of Chinese culture to most Americans is what makes it most terrifying. The racism directed at other ethnic blocs (African-Americans, Hispanics) seems to deal with “known”, familiar entities; as a country, we have a lot of collective day to day exposure, as well as much historical exposure, to both African-Americans and Hispanics, but not so much with Chinese.
Adjusting to the changing world order is going to be hard for America and Americans. Chinese-Americans can help; we ABCs have deep, conflicting roots steeped in both cultures. Get to know us, leverage our innate existential angst, and learn about and welcome your new overlords.
If you can read this, it will happen in your lifetime.
1: Both the backhanded unintentional flavour as well as good ol’ fashioned out and out “I hate different people” kind
Normal friends and family, just skip this post. Trust me.
Recently, while doing some PCI slot symlink work, I noticed that we weren’t calling pci_release_dev() after taking a card offline (via sysfs). Well, at least not the first time, due to a leaked refcount in pci_get_dev_by_id(). gregkh fixed it, so that’s good, but I had a slightly difficult time tracking down the exact problem.
See, I had instrumented pci_dev_get() and pci_dev_put() to call dump_stack() every time the device that I cared about was touched:
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -789,6 +789,11 @@ struct pci_dev *pci_dev_get(struct pci_dev *dev)
{
if (dev)
get_device(&dev->dev);
+ if (dev && (dev->bus->number == 1) && (PCI_SLOT(dev->devfn) == 2)) {
+ dump_stack();
+ printk(KERN_INFO "dev refcount: %d\n",
+ atomic_read(&dev->dev.kobj.kref.refcount));
+ }
return dev;
}
[mutatis mutandis for pci_dev_put()]
But I wasn’t getting all the information I needed. Other pieces of code were playing with that device’s refcount too. So I did this instead (thanks to willy for the hint!):
@@ -983,7 +984,20 @@ int device_register(struct device *dev)
*/
struct device *get_device(struct device *dev)
{
- return dev ? to_dev(kobject_get(&dev->kobj)) : NULL;
+
+ if (!dev)
+ return NULL;
+
+ if (dev->bus == &pci_bus_type) {
+ struct pci_dev *pci_dev = to_pci_dev(dev);
+ if ((pci_dev->bus->number == 1) && (PCI_SLOT(pci_dev->devfn) == 2)) {
+ dump_stack();
+ printk(KERN_INFO "dev refcount: %d\n",
+ atomic_read(&pci_dev->dev.kobj.kref.refcount));
+ }
+ }
+
+ return to_dev(kobject_get(&dev->kobj));
}
Armed with that patch, this is the list of code paths (as of 2.6.27) that can affect a struct pci_dev’s refcount:
* pci_dev_get * pci_dev_put * device_add -> get_device * device_add -> klist_add_tail -> ... -> get_device * device_del -> put_device * device_del -> klist_del -> ... -> put_device * bus_attach_device -> klist_add_tail -> ... -> get_device * bus_remove_device -> klist_del -> ... -> put_device * acpi_platform_notify -> acpi_bind_one -> get_device
There are lots of code paths that can potentially directly call device_add/del so if you’re debugging that, you’ll need to figure out which ones affect you. I included that acpi_bind_one() as an example of a surprising place where we might directly call get_device().
The only surprising gotcha might be the calls to klist_add_tail/klist_del. Those calls will be non-obvious to grep for while debugging your device’s lifetime. So if you are wondering why your struct pci_dev isn’t calling its ->release() properly, just patch get_device() directly, and be prepared to stare at the output for a while. Good luck.
[Note that device_add bumps the refcount by 2, but then calls put_device() during cleanup, for a net gain of +1.]
what goes in Reno…
Thu, Sep 11, 2008 Denver, CO (DEN) - Reno, NV (RNO)
Kernel Summit/Linux Plumber’s Conf
Sun, Sep 14, 2008 Reno, NV (RNO) - Portland, OR (PDX)
Falconer + G-unit’s wedding
Thu, Sep 25, 2008 Denver, CO (DEN) - Chicago, IL (ORD)
Becca in Madison
Thu, Oct 30, 2008 Denver, CO (DEN) - Chicago, IL (ORD)
The folks in NJ + big golden birthday celebration
Sun, Dec 21, 2008 Denver, CO (DEN) - New York, NY (LGA)
My talk for the 1st ever Linux Plumber’s Conf was accepted: Physical PCI slots: A little bit goes a long way.
Looking at the rest of the speakers schedule, I’m pretty excited by the lineup. These should be some great talks. The only bummer is that some of the talks I’m interested in overlap, but I’m guessing (hoping?) that the fine folks in charge will video everything and post them afterwards.
Ugh, prepping slideware is going to … suck. Only one month left.
And it was totally worth it.
the place of honor
Home decor +1
