Hi, please, cc me, I am not subscribed to lkml. > Hi, > > [lkml.org still broken --> no accurate mail header info possible...] > > Just to ask the obvious: > I assume using /sys/bus/pci/rescan does not help once it's broken? > (since the machine comes up empty at initial-boot scan, too) I will try it, too, but I am not sure it would work. Currently I can't test it because the last time I completely discharged the battery. I also disconnected it to be able to get the realtek chip back immediately for faster testing. Now, that I have reconnected the battery, I need to wait for it to be charged somewhat to be able to reproduce losing the network chip. > Also, you could try diffing lspci -vvxxx -s.... output > of working vs. "distorting" kernel version - perhaps some register setup > has been changed (e.g. due to power management improvements or some such), > which may encourage the card > to get a problematic/corrupt state. I attached a tarball that contains lspci -vvxxx for - all devices / only the network chip - before / after "modprobe r8169" - for all 3 kernel versions tested. I figured out that if I type the modprobe and lspci in the same command line, I can get diagnostics out of the machine, after all. It's not just the Realtek chip that has changed parameters. (Vague idea) I noticed that some devices have changed like this: - Memory behind bridge: 80000000-801fffff - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff + Memory behind bridge: ff000000-ff1fffff + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff Can't this cause a problem? E.g. programming the bridge with an address range that the bridge doesn't actually support? > > > Upon powering off the system, > > the r8169 driver compained about "rtl_eriar_cond = 1 loop 100" > > Yup, that seems to be > rtl_eri_read() in ethernet/realtek/r8169.c > waiting on low condition of > RTL_R32(ERIAR) & ERIAR_FLAG; I found that, too, and I think it is a symptom of instead of the cause. Thanks for your efforts, Zoltán Böszörményi