* [Bug] invalid mac address after rebooting (kernel 2.6.11.5) @ 2005-03-23 12:24 Peter Baumann 2005-03-24 2:52 ` Andrew Morton 0 siblings, 1 reply; 16+ messages in thread From: Peter Baumann @ 2005-03-23 12:24 UTC (permalink / raw) To: linux-kernel I'm hitting an annoying bug in kernel 2.6.11.5 Every time I _reboot_ (warmstart) my pc my two network cards won't get recognized any longer. Following error message appears on my screen: PCI: Enabling device 0000:00:0b.0 (0000 -> 0003) ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19 PCI: Setting latency timer of device 0000:00:0b.0 to 64 *** EEPROM MAC address is invalid. 3c59x: vortex_probe1 fails. Returns -22 3c59x: probe of 0000:00:0b.0 failed with error -22 PCI: Enabling device 0000:00:0d.0 (0000 -> 0003) ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19 0000:00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers LK1.1.19 PCI: Setting latency timer of device 0000:00:0d.0 to 64 *** EEPROM MAC address is invalid. 3c59x: vortex_probe1 fails. Returns -22 3c59x: probe of 0000:00:0d.0 failed with error -22 This doesn't happen with older kernels (especially with 2.6.10) and so I've done a binary search and narrowed it down to 2.6.11-rc5 where it first hits me. My config, lspci output and the dmesg output of the working and non-working version can be found at [1] Feel free to ask if any information is missing or if I am supposed to try a patch. Greetings, Peter Baumann PS: Please reply to me directly as I am not subscribed to lkml [1] http://wwwcip.informatik.uni-erlangen.de/~siprbaum/kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bug] invalid mac address after rebooting (kernel 2.6.11.5) 2005-03-23 12:24 [Bug] invalid mac address after rebooting (kernel 2.6.11.5) Peter Baumann @ 2005-03-24 2:52 ` Andrew Morton 2005-03-24 11:01 ` Peter Baumann 2005-04-12 8:59 ` [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2) Peter Baumann 0 siblings, 2 replies; 16+ messages in thread From: Andrew Morton @ 2005-03-24 2:52 UTC (permalink / raw) To: Peter Baumann; +Cc: linux-kernel Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> wrote: > > > I'm hitting an annoying bug in kernel 2.6.11.5 > > Every time I _reboot_ (warmstart) my pc my two network cards won't get > recognized any longer. > > Following error message appears on my screen: > > PCI: Enabling device 0000:00:0b.0 (0000 -> 0003) > ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html > 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19 > PCI: Setting latency timer of device 0000:00:0b.0 to 64 > *** EEPROM MAC address is invalid. > 3c59x: vortex_probe1 fails. Returns -22 > 3c59x: probe of 0000:00:0b.0 failed with error -22 > PCI: Enabling device 0000:00:0d.0 (0000 -> 0003) > ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19 > 0000:00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers LK1.1.19 > PCI: Setting latency timer of device 0000:00:0d.0 to 64 > *** EEPROM MAC address is invalid. > 3c59x: vortex_probe1 fails. Returns -22 > 3c59x: probe of 0000:00:0d.0 failed with error -22 > > This doesn't happen with older kernels (especially with 2.6.10) and so > I've done a binary search and narrowed it down to 2.6.11-rc5 where it > first hits me. > > My config, lspci output and the dmesg output of the working and non-working > version can be found at [1] > > Feel free to ask if any information is missing or if I am supposed to try > a patch. Thanks for doing the bsearch - it helps. There were no driver changes between 2.6.11-rc4 and 2.6.11-rc5. The only PCI change I see is --- drivers/pci/pci.c 22 Jan 2005 03:20:37 -0000 1.71 +++ drivers/pci/pci.c 24 Feb 2005 18:02:37 -0000 1.72 @@ -268,7 +268,7 @@ return -EIO; pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc); - if ((pmc & PCI_PM_CAP_VER_MASK) != 2) { + if ((pmc & PCI_PM_CAP_VER_MASK) > 2) { printk(KERN_DEBUG "PCI: %s has unsupported PM cap regs version (%u)\n", dev->slot_name, pmc & PCI_PM_CAP_VER_MASK); and you're not getting that message (are you?) Nothing much in arch/i386.. There were some ACPI changes, which is always a worry ;) Does that machine run OK without ACPI support? If so, could you determine whether disabling ACPI fixes things up? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bug] invalid mac address after rebooting (kernel 2.6.11.5) 2005-03-24 2:52 ` Andrew Morton @ 2005-03-24 11:01 ` Peter Baumann 2005-03-24 11:07 ` Andrew Morton 2005-04-03 13:40 ` Daniel Drake 2005-04-12 8:59 ` [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2) Peter Baumann 1 sibling, 2 replies; 16+ messages in thread From: Peter Baumann @ 2005-03-24 11:01 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote: > Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> wrote: > > > > > > I'm hitting an annoying bug in kernel 2.6.11.5 > > > > Every time I _reboot_ (warmstart) my pc my two network cards won't get > > recognized any longer. > > > > Following error message appears on my screen: > > > > PCI: Enabling device 0000:00:0b.0 (0000 -> 0003) > > ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 > > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html > > 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19 > > PCI: Setting latency timer of device 0000:00:0b.0 to 64 > > *** EEPROM MAC address is invalid. > > 3c59x: vortex_probe1 fails. Returns -22 > > 3c59x: probe of 0000:00:0b.0 failed with error -22 > > PCI: Enabling device 0000:00:0d.0 (0000 -> 0003) > > ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19 > > 0000:00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers LK1.1.19 > > PCI: Setting latency timer of device 0000:00:0d.0 to 64 > > *** EEPROM MAC address is invalid. > > 3c59x: vortex_probe1 fails. Returns -22 > > 3c59x: probe of 0000:00:0d.0 failed with error -22 > > > > This doesn't happen with older kernels (especially with 2.6.10) and so > > I've done a binary search and narrowed it down to 2.6.11-rc5 where it > > first hits me. > > > > My config, lspci output and the dmesg output of the working and non-working > > version can be found at [1] > > > > Feel free to ask if any information is missing or if I am supposed to try > > a patch. > > Thanks for doing the bsearch - it helps. > > There were no driver changes between 2.6.11-rc4 and 2.6.11-rc5. > > The only PCI change I see is > > --- drivers/pci/pci.c 22 Jan 2005 03:20:37 -0000 1.71 > +++ drivers/pci/pci.c 24 Feb 2005 18:02:37 -0000 1.72 > @@ -268,7 +268,7 @@ > return -EIO; > > pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc); > - if ((pmc & PCI_PM_CAP_VER_MASK) != 2) { > + if ((pmc & PCI_PM_CAP_VER_MASK) > 2) { > printk(KERN_DEBUG > "PCI: %s has unsupported PM cap regs version (%u)\n", > dev->slot_name, pmc & PCI_PM_CAP_VER_MASK); > > and you're not getting that message (are you?) > Reverting the above patch solved it. But _now_ I get the message. (dmesg output with above patch reverted at the end of the mail) > Nothing much in arch/i386.. > > There were some ACPI changes, which is always a worry ;) Does that machine > run OK without ACPI support? If so, could you determine whether disabling > ACPI fixes things up? > Hm. I tried it with 2.6.11.5 by appending acpi=off at the cmdline but as I remember it hasn't changed anything. Or do I have to specify someting else at the commandline to deactivate acpi? Greetings, Peter Baumann Linux version 2.6.11-rc5-revert (peter@xp) (gcc version 3.3.5 (Debian 1:3.3.5-12)) #2 Thu Mar 24 11:44:28 CET 2005 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009e800 (usable) BIOS-e820: 000000000009e800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS) BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 511MB LOWMEM available. found SMP MP-table at 000f59e0 On node 0 totalpages: 131056 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 126960 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 DMI 2.2 present. ACPI: RSDP (v000 KT400 ) @ 0x000f7410 ACPI: RSDT (v001 KT400 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3000 ACPI: FADT (v001 KT400 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040 ACPI: MADT (v001 KT400 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff71c0 ACPI: DSDT (v001 KT400 AWRDACPI 0x00001000 MSFT 0x0100000d) @ 0x00000000 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, version 3, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 20000000 (gap: 20000000:dec00000) Built 1 zonelists Kernel command line: root=/dev/md2 ro ide4=noprobe ide5=noprobe debug ide_setup: ide4=noprobe ide_setup: ide5=noprobe mapped APIC to ffffd000 (fee00000) mapped IOAPIC to ffffc000 (fec00000) Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 1537.147 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 515240k/524224k available (2052k kernel code, 8424k reserved, 1060k data, 180k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 3022.84 BogoMIPS (lpj=1511424) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0383fbff c1c3fbff 00000000 00000000 00000000 00000000 00000000 CPU: After vendor identify, caps: 0383fbff c1c3fbff 00000000 00000000 00000000 00000000 00000000 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383fbff c1c3fbff 00000000 00000020 00000000 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Athlon(tm) XP 1800+ stepping 01 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=2 pin2=-1 NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfb370, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050211 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Via IRQ fixup ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [ALKA] (IRQs 20) *0, disabled. ACPI: PCI Interrupt Link [ALKB] (IRQs 21) *0, disabled. ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *0, disabled. ACPI: PCI Interrupt Link [ALKD] (IRQs 23) *0, disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 13 devices PCI: Using ACPI for IRQ routing ** PCI interrupts are no longer routed automatically. If this ** causes a device to stop working, it is probably because the ** driver failed to call pci_enable_device(). As a temporary ** workaround, the "pci=routeirq" argument restores the old ** behavior. If this argument makes the device work again, ** please email the output of "lspci" to bjorn.helgaas@hp.com ** so I can fix the driver. pnp: 00:01: ioport range 0x4000-0x407f could not be reserved pnp: 00:01: ioport range 0x5000-0x500f has been reserved Initializing Cryptographic API Real Time Clock Driver v1.12 Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected VIA KT400/KT400A/KT600 chipset agpgart: Maximum main memory to use for agp memory: 439M agpgart: AGP aperture is 32M @ 0xe0000000 [drm] Initialized drm 1.0.0 20040925 ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16 [drm] Initialized mga 3.1.0 20021029 on minor 0: Matrox Graphics, Inc. MGA G400 AGP ACPI: PS/2 Keyboard Controller [PS2K] at I/O 0x60, 0x64, irq 1 ACPI: PS/2 Mouse Controller [PS2M] at irq 12 serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) PCI: 0000:00:0b.0 has unsupported PM cap regs version (1) ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xac00. Vers LK1.1.19 PCI: 0000:00:0d.0 has unsupported PM cap regs version (1) ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19 0000:00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xb000. Vers LK1.1.19 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx HPT370A: IDE controller at PCI slot 0000:00:08.0 ACPI: PCI interrupt 0000:00:08.0[A] -> GSI 16 (level, low) -> IRQ 16 HPT370A: chipset revision 4 HPT37X: using 33MHz PCI clock HPT370A: 100% native mode on irq 16 ide0: BM-DMA at 0xa000-0xa007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xa008-0xa00f, BIOS settings: hdc:pio, hdd:pio Probing IDE interface ide0... hda: WDC WD800BB-00CAA0, ATA DISK drive ide0 at 0x9000-0x9007,0x9402 on irq 16 Probing IDE interface ide1... VP_IDE: IDE controller at PCI slot 0000:00:11.1 ACPI: PCI Interrupt Link [ALKA] BIOS reported IRQ 0, using IRQ 20 ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 20 ACPI: PCI interrupt 0000:00:11.1[A] -> GSI 20 (level, low) -> IRQ 20 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci0000:00:11.1 ide2: BM-DMA at 0xc000-0xc007, BIOS settings: hde:DMA, hdf:pio ide3: BM-DMA at 0xc008-0xc00f, BIOS settings: hdg:DMA, hdh:DMA Probing IDE interface ide2... hde: WDC WD1200JB-00EVA0, ATA DISK drive ide2 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide3... hdg: WDC WD1200JB-00EVA0, ATA DISK drive hdh: Pioneer DVD-ROM ATAPIModel DVD-105S 012, ATAPI CD/DVD-ROM drive ide3 at 0x170-0x177,0x376 on irq 15 Probing IDE interface ide1... hda: max request size: 128KiB hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100) hda: cache flushes not supported hda: hda1 hda2 hda4 < hda5 hda6 hda7 hda8 hda9 > hde: max request size: 1024KiB hde: 234441648 sectors (120034 MB) w/8192KiB Cache, CHS=16383/255/63, UDMA(100) hde: cache flushes supported hde: hde1 hde2 hde4 < hde5 hde6 hde7 hde8 hde9 > hdg: max request size: 1024KiB hdg: 234441648 sectors (120034 MB) w/8192KiB Cache, CHS=16383/255/63, UDMA(100) hdg: cache flushes supported hdg: hdg1 hdg2 hdg4 < hdg5 hdg6 hdg7 hdg8 hdg9 > hdh: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard on isa0060/serio0 input: ImExPS/2 Generic Explorer Mouse on isa0060/serio1 input: PC Speaker md: linear personality registered as nr 1 md: raid0 personality registered as nr 2 md: raid1 personality registered as nr 3 md: raid5 personality registered as nr 4 raid5: automatically using best checksumming function: pIII_sse pIII_sse : 4180.000 MB/sec raid5: using function: pIII_sse (4180.000 MB/sec) md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27 NET: Registered protocol family 2 IP: routing cache hash table of 4096 buckets, 32Kbytes TCP established hash table entries: 32768 (order: 6, 262144 bytes) TCP bind hash table entries: 32768 (order: 5, 131072 bytes) TCP: Hash tables configured (established 32768 bind 32768) NET: Registered protocol family 1 NET: Registered protocol family 17 ACPI wakeup devices: PCI0 USB0 USB1 USB2 USB6 USB7 USB8 USB9 LAN0 UAR1 ECP1 ACPI: (supports S0 S1 S3 S4 S5) md: Autodetecting RAID arrays. md: invalid raid superblock magic on hda1 md: hda1 has invalid sb, not importing! md: autorun ... md: considering hdg8 ... md: adding hdg8 ... md: hdg7 has different UUID to hdg8 md: hdg6 has different UUID to hdg8 md: hdg1 has different UUID to hdg8 md: adding hde8 ... md: hde7 has different UUID to hdg8 md: hde6 has different UUID to hdg8 md: hde1 has different UUID to hdg8 md: adding hda8 ... md: hda7 has different UUID to hdg8 md: hda6 has different UUID to hdg8 md: created md4 md: bind<hda8> md: bind<hde8> md: bind<hdg8> md: running: <hdg8><hde8><hda8> raid5: device hdg8 operational as raid disk 2 raid5: device hde8 operational as raid disk 1 raid5: device hda8 operational as raid disk 0 raid5: allocated 3154kB for md4 raid5: raid level 5 set md4 active with 3 out of 3 devices, algorithm 2 RAID5 conf printout: --- rd:3 wd:3 fd:0 disk 0, o:1, dev:hda8 disk 1, o:1, dev:hde8 disk 2, o:1, dev:hdg8 md: considering hdg7 ... md: adding hdg7 ... md: hdg6 has different UUID to hdg7 md: hdg1 has different UUID to hdg7 md: adding hde7 ... md: hde6 has different UUID to hdg7 md: hde1 has different UUID to hdg7 md: adding hda7 ... md: hda6 has different UUID to hdg7 md: created md3 md: bind<hda7> md: bind<hde7> md: bind<hdg7> md: running: <hdg7><hde7><hda7> raid5: device hdg7 operational as raid disk 2 raid5: device hde7 operational as raid disk 1 raid5: device hda7 operational as raid disk 0 raid5: allocated 3154kB for md3 raid5: raid level 5 set md3 active with 3 out of 3 devices, algorithm 2 RAID5 conf printout: --- rd:3 wd:3 fd:0 disk 0, o:1, dev:hda7 disk 1, o:1, dev:hde7 disk 2, o:1, dev:hdg7 md: considering hdg6 ... md: adding hdg6 ... md: hdg1 has different UUID to hdg6 md: adding hde6 ... md: hde1 has different UUID to hdg6 md: adding hda6 ... md: created md2 md: bind<hda6> md: bind<hde6> md: bind<hdg6> md: running: <hdg6><hde6><hda6> raid5: device hdg6 operational as raid disk 2 raid5: device hde6 operational as raid disk 1 raid5: device hda6 operational as raid disk 0 raid5: allocated 3154kB for md2 raid5: raid level 5 set md2 active with 3 out of 3 devices, algorithm 2 RAID5 conf printout: --- rd:3 wd:3 fd:0 disk 0, o:1, dev:hda6 disk 1, o:1, dev:hde6 disk 2, o:1, dev:hdg6 md: considering hdg1 ... md: adding hdg1 ... md: adding hde1 ... md: created md0 md: bind<hde1> md: bind<hdg1> md: running: <hdg1><hde1> raid1: raid set md0 active with 2 out of 2 mirrors md: ... autorun DONE. EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 180k freed kjournald starting. Commit interval 5 seconds EXT3 FS on md2, internal journal CSLIP: code copyright 1989 Regents of the University of California PPP generic driver version 2.4.2 device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com cdrom: open failed. kjournald starting. Commit interval 5 seconds EXT3 FS on md3, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md4, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md0, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on hde9, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on hdg9, internal journal EXT3-fs: mounted filesystem with ordered data mode. PCI: 0000:00:09.0 has unsupported PM cap regs version (1) ACPI: PCI interrupt 0000:00:09.0[A] -> GSI 17 (level, low) -> IRQ 17 Linux video capture interface: v1.00 bttv: driver version 0.9.15 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). ACPI: PCI interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ 18 bttv0: Bt878 (rev 17) at 0000:00:0a.0, irq: 18, latency: 32, mmio: 0xe8000000 bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb bttv0: using: Hauppauge (bt878) [card=10,autodetected] bttv0: gpio: en=00000000, out=00000000 in=00ffffdb [init] bttv0: Hauppauge/Voodoo msp34xx: reset line init [5] tveeprom: Hauppauge: model = 61344, rev = D421, serial# = 3911831 tveeprom: tuner = Philips FM1216 (idx = 21, type = 5) tveeprom: tuner fmt = PAL(B/G) (eeprom = 0x04, v4l2 = 0x00000007) tveeprom: audio_processor = MSP3415 (type = 6) bttv0: using tuner=5 bttv0: i2c: checking for MSP34xx @ 0x80... found msp34xx: init: chip=MSP3415D-A2 +nicam +simple mode=simple msp3410: daemon started bttv0: i2c: checking for TDA9875 @ 0xb0... not found bttv0: i2c: checking for TDA7432 @ 0x8a... not found tvaudio: TV audio decoder + audio/video mux driver tvaudio: known chips: tda9840,tda9873h,tda9874h/a,tda9850,tda9855,tea6300,tea6320,tea6420,tda8425,pic16c54 (PV951),ta8874z bttv0: i2c: checking for TDA9887 @ 0x86... not found tuner: chip found at addr 0xc2 i2c-bus bt878 #0 [sw] tuner: type set to 5 (Philips PAL_BG (FI1216 and compatibles)) by bt878 #0 [sw] bttv0: registered device video0 bttv0: registered device vbi0 bttv0: registered device radio0 bttv0: PLL: 28636363 => 35468950 .. ok ACPI: PCI interrupt 0000:00:0a.1[A] -> GSI 18 (level, low) -> IRQ 18 usbcore: registered new driver usbfs usbcore: registered new driver hub USB Universal Host Controller Interface driver v2.2 ACPI: PCI Interrupt Link [ALKB] BIOS reported IRQ 0, using IRQ 21 ACPI: PCI Interrupt Link [ALKB] enabled at IRQ 21 ACPI: PCI interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 21 uhci_hcd 0000:00:10.0: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller uhci_hcd 0000:00:10.0: irq 21, io base 0xb400 uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 1 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:10.1[B] -> GSI 21 (level, low) -> IRQ 21 uhci_hcd 0000:00:10.1: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#2) uhci_hcd 0000:00:10.1: irq 21, io base 0xb800 uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:10.2[C] -> GSI 21 (level, low) -> IRQ 21 uhci_hcd 0000:00:10.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#3) uhci_hcd 0000:00:10.2: irq 21, io base 0xbc00 uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 3 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:10.3[D] -> GSI 21 (level, low) -> IRQ 21 ehci_hcd 0000:00:10.3: VIA Technologies, Inc. USB 2.0 ehci_hcd 0000:00:10.3: irq 21, pci mem 0xe8004000 ehci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 4 ehci_hcd 0000:00:10.3: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004 hub 4-0:1.0: USB hub found hub 4-0:1.0: 6 ports detected parport: PnPBIOS parport detected. parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA] PCI: 0000:00:0b.0 has unsupported PM cap regs version (1) PCI: 0000:00:0b.0 has unsupported PM cap regs version (1) ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 PCI: 0000:00:0d.0 has unsupported PM cap regs version (1) PCI: 0000:00:0d.0 has unsupported PM cap regs version (1) ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19 ACPI: CPU0 (power states: C1[C1] C2[C2]) ACPI: Power Button (FF) [PWRF] ACPI: Fan [FAN] (on) ACPI: Thermal Zone [THRM] (39 C) lp0: using parport0 (interrupt-driven). PCI: 0000:00:0b.0 has unsupported PM cap regs version (1) PCI: 0000:00:0b.0 has unsupported PM cap regs version (1) PCI: 0000:00:0b.0 has unsupported PM cap regs version (1) PCI: 0000:00:0b.0 has unsupported PM cap regs version (1) PCI: 0000:00:0b.0 has unsupported PM cap regs version (1) PCI: 0000:00:0b.0 has unsupported PM cap regs version (1) PCI: 0000:00:0b.0 has unsupported PM cap regs version (1) PCI: 0000:00:0d.0 has unsupported PM cap regs version (1) PCI: 0000:00:0d.0 has unsupported PM cap regs version (1) PCI: 0000:00:0d.0 has unsupported PM cap regs version (1) PCI: 0000:00:0d.0 has unsupported PM cap regs version (1) PCI: 0000:00:0d.0 has unsupported PM cap regs version (1) Bluetooth: Core ver 2.7 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP ver 2.7 Bluetooth: L2CAP socket layer initialized Bluetooth: RFCOMM ver 1.5 Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bug] invalid mac address after rebooting (kernel 2.6.11.5) 2005-03-24 11:01 ` Peter Baumann @ 2005-03-24 11:07 ` Andrew Morton 2005-03-24 11:54 ` Peter Baumann 2005-04-03 13:40 ` Daniel Drake 1 sibling, 1 reply; 16+ messages in thread From: Andrew Morton @ 2005-03-24 11:07 UTC (permalink / raw) To: Peter Baumann; +Cc: linux-kernel, Greg KH Peter Baumann <waste.manager@gmx.de> wrote: > > > > > The only PCI change I see is > > > > --- drivers/pci/pci.c 22 Jan 2005 03:20:37 -0000 1.71 > > +++ drivers/pci/pci.c 24 Feb 2005 18:02:37 -0000 1.72 > > @@ -268,7 +268,7 @@ > > return -EIO; > > > > pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc); > > - if ((pmc & PCI_PM_CAP_VER_MASK) != 2) { > > + if ((pmc & PCI_PM_CAP_VER_MASK) > 2) { > > printk(KERN_DEBUG > > "PCI: %s has unsupported PM cap regs version (%u)\n", > > dev->slot_name, pmc & PCI_PM_CAP_VER_MASK); > > > > and you're not getting that message (are you?) > > > > Reverting the above patch solved it. But _now_ I get the message. > (dmesg output with above patch reverted at the end of the mail) Greg, help! > > Nothing much in arch/i386.. > > > > There were some ACPI changes, which is always a worry ;) Does that machine > > run OK without ACPI support? If so, could you determine whether disabling > > ACPI fixes things up? > > > Hm. I tried it with 2.6.11.5 by appending acpi=off at the cmdline but > as I remember it hasn't changed anything. Or do I have to specify > someting else at the commandline to deactivate acpi? We like to change these things so people send us more email. According to Documentation/kernel-parameters.txt, acpi=off should still work. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bug] invalid mac address after rebooting (kernel 2.6.11.5) 2005-03-24 11:07 ` Andrew Morton @ 2005-03-24 11:54 ` Peter Baumann 0 siblings, 0 replies; 16+ messages in thread From: Peter Baumann @ 2005-03-24 11:54 UTC (permalink / raw) To: linux-kernel On Thu, Mar 24, 2005 at 03:07:51AM -0800, Andrew Morton wrote: > Peter Baumann <waste.manager@gmx.de> wrote: > > > > > > > > The only PCI change I see is > > > > > > --- drivers/pci/pci.c 22 Jan 2005 03:20:37 -0000 1.71 > > > +++ drivers/pci/pci.c 24 Feb 2005 18:02:37 -0000 1.72 > > > @@ -268,7 +268,7 @@ > > > return -EIO; > > > > > > pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc); > > > - if ((pmc & PCI_PM_CAP_VER_MASK) != 2) { > > > + if ((pmc & PCI_PM_CAP_VER_MASK) > 2) { > > > printk(KERN_DEBUG > > > "PCI: %s has unsupported PM cap regs version (%u)\n", > > > dev->slot_name, pmc & PCI_PM_CAP_VER_MASK); > > > > > > and you're not getting that message (are you?) > > > > > > > Reverting the above patch solved it. But _now_ I get the message. > > (dmesg output with above patch reverted at the end of the mail) > > Greg, help! > > > > Nothing much in arch/i386.. > > > > > > There were some ACPI changes, which is always a worry ;) Does that machine > > > run OK without ACPI support? If so, could you determine whether disabling > > > ACPI fixes things up? > > > > > Hm. I tried it with 2.6.11.5 by appending acpi=off at the cmdline but > > as I remember it hasn't changed anything. Or do I have to specify > > someting else at the commandline to deactivate acpi? > > We like to change these things so people send us more email. > > According to Documentation/kernel-parameters.txt, acpi=off should still work. > Yes. That's were I was looking for :-) Sorry for my bad english but I meant that switching acpi off did not change anything releated to the bug. Of course it deactivates acpi. Peter ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bug] invalid mac address after rebooting (kernel 2.6.11.5) 2005-03-24 11:01 ` Peter Baumann 2005-03-24 11:07 ` Andrew Morton @ 2005-04-03 13:40 ` Daniel Drake 1 sibling, 0 replies; 16+ messages in thread From: Daniel Drake @ 2005-04-03 13:40 UTC (permalink / raw) To: Peter Baumann; +Cc: Andrew Morton, linux-kernel, habraken, greg, aniel.ritz Peter Baumann wrote: > On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote: > >>Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> wrote: >> >>> >>>I'm hitting an annoying bug in kernel 2.6.11.5 >>> >>>Every time I _reboot_ (warmstart) my pc my two network cards won't get >>>recognized any longer. >>> >>>Following error message appears on my screen: >>> >>>PCI: Enabling device 0000:00:0b.0 (0000 -> 0003) >>>ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 >>>3c59x: Donald Becker and others. www.scyld.com/network/vortex.html >>>0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19 >>>PCI: Setting latency timer of device 0000:00:0b.0 to 64 >>>*** EEPROM MAC address is invalid. >>>3c59x: vortex_probe1 fails. Returns -22 >>>3c59x: probe of 0000:00:0b.0 failed with error -22 >>>PCI: Enabling device 0000:00:0d.0 (0000 -> 0003) >>>ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19 >>>0000:00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers LK1.1.19 >>>PCI: Setting latency timer of device 0000:00:0d.0 to 64 >>>*** EEPROM MAC address is invalid. >>>3c59x: vortex_probe1 fails. Returns -22 >>>3c59x: probe of 0000:00:0d.0 failed with error -22 >>> >>>This doesn't happen with older kernels (especially with 2.6.10) and so >>>I've done a binary search and narrowed it down to 2.6.11-rc5 where it >>>first hits me. >>> >>>My config, lspci output and the dmesg output of the working and non-working >>>version can be found at [1] >>> >>>Feel free to ask if any information is missing or if I am supposed to try >>>a patch. >> >>Thanks for doing the bsearch - it helps. >> >>There were no driver changes between 2.6.11-rc4 and 2.6.11-rc5. >> >>The only PCI change I see is >> >>--- drivers/pci/pci.c 22 Jan 2005 03:20:37 -0000 1.71 >>+++ drivers/pci/pci.c 24 Feb 2005 18:02:37 -0000 1.72 >>@@ -268,7 +268,7 @@ >> return -EIO; >> >> pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc); >>- if ((pmc & PCI_PM_CAP_VER_MASK) != 2) { >>+ if ((pmc & PCI_PM_CAP_VER_MASK) > 2) { >> printk(KERN_DEBUG >> "PCI: %s has unsupported PM cap regs version (%u)\n", >> dev->slot_name, pmc & PCI_PM_CAP_VER_MASK); >> >>and you're not getting that message (are you?) >> > > > Reverting the above patch solved it. A gentoo user also reported this, but according to the bug report, this happens on every bootup (as opposed to only every warm boot) http://bugs.gentoo.org/87142 I asked him to try reverting the patch shown above and that helped his situation too. What's next towards getting this fixed for real? Daniel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2) 2005-03-24 2:52 ` Andrew Morton 2005-03-24 11:01 ` Peter Baumann @ 2005-04-12 8:59 ` Peter Baumann 2005-04-12 9:09 ` Andrew Morton 1 sibling, 1 reply; 16+ messages in thread From: Peter Baumann @ 2005-04-12 8:59 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, Greg KH On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote: > Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> wrote: > > > > > > I'm hitting an annoying bug in kernel 2.6.11.5 > > > > Every time I _reboot_ (warmstart) my pc my two network cards won't get > > recognized any longer. > > > > Following error message appears on my screen: > > > > PCI: Enabling device 0000:00:0b.0 (0000 -> 0003) > > ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 > > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html > > 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19 > > PCI: Setting latency timer of device 0000:00:0b.0 to 64 > > *** EEPROM MAC address is invalid. > > 3c59x: vortex_probe1 fails. Returns -22 > > 3c59x: probe of 0000:00:0b.0 failed with error -22 > > PCI: Enabling device 0000:00:0d.0 (0000 -> 0003) > > ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19 > > 0000:00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers LK1.1.19 > > PCI: Setting latency timer of device 0000:00:0d.0 to 64 > > *** EEPROM MAC address is invalid. > > 3c59x: vortex_probe1 fails. Returns -22 > > 3c59x: probe of 0000:00:0d.0 failed with error -22 > > > > This doesn't happen with older kernels (especially with 2.6.10) and so > > I've done a binary search and narrowed it down to 2.6.11-rc5 where it > > first hits me. > > > > My config, lspci output and the dmesg output of the working and non-working > > version can be found at [1] > > > > Feel free to ask if any information is missing or if I am supposed to try > > a patch. > > Thanks for doing the bsearch - it helps. > > There were no driver changes between 2.6.11-rc4 and 2.6.11-rc5. > > The only PCI change I see is > > --- drivers/pci/pci.c 22 Jan 2005 03:20:37 -0000 1.71 > +++ drivers/pci/pci.c 24 Feb 2005 18:02:37 -0000 1.72 > @@ -268,7 +268,7 @@ > return -EIO; > > pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc); > - if ((pmc & PCI_PM_CAP_VER_MASK) != 2) { > + if ((pmc & PCI_PM_CAP_VER_MASK) > 2) { > printk(KERN_DEBUG > "PCI: %s has unsupported PM cap regs version (%u)\n", > dev->slot_name, pmc & PCI_PM_CAP_VER_MASK); > > and you're not getting that message (are you?) > I have still the problem described above with 2.6.12-rc2-mm2 and reverting the above patch solved it. And yes, now I get many of those PCI: 0000:00:0b.0 has unsupported PM cap regs version (1) PCI: 0000:00:0d.0 has unsupported PM cap regs version (1) PCI: 0000:00:09.0 has unsupported PM cap regs version (1) messages. Greetings, Peter Baumann ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2) 2005-04-12 8:59 ` [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2) Peter Baumann @ 2005-04-12 9:09 ` Andrew Morton 2005-04-13 19:24 ` Daniel Ritz 0 siblings, 1 reply; 16+ messages in thread From: Andrew Morton @ 2005-04-12 9:09 UTC (permalink / raw) To: Peter Baumann; +Cc: linux-kernel, greg, daniel.ritz Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> wrote: > > On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote: > > Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> wrote: > > > > > > > > > I'm hitting an annoying bug in kernel 2.6.11.5 > > > > > > Every time I _reboot_ (warmstart) my pc my two network cards won't get > > > recognized any longer. > > > > > > Following error message appears on my screen: > > > > > > PCI: Enabling device 0000:00:0b.0 (0000 -> 0003) > > > ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 > > > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html > > > 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19 > > > PCI: Setting latency timer of device 0000:00:0b.0 to 64 > > > *** EEPROM MAC address is invalid. > > > 3c59x: vortex_probe1 fails. Returns -22 > > > 3c59x: probe of 0000:00:0b.0 failed with error -22 > > > PCI: Enabling device 0000:00:0d.0 (0000 -> 0003) > > > ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19 > > > 0000:00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers LK1.1.19 > > > PCI: Setting latency timer of device 0000:00:0d.0 to 64 > > > *** EEPROM MAC address is invalid. > > > 3c59x: vortex_probe1 fails. Returns -22 > > > 3c59x: probe of 0000:00:0d.0 failed with error -22 > > > > > > This doesn't happen with older kernels (especially with 2.6.10) and so > > > I've done a binary search and narrowed it down to 2.6.11-rc5 where it > > > first hits me. > > > > > > My config, lspci output and the dmesg output of the working and non-working > > > version can be found at [1] > > > > > > Feel free to ask if any information is missing or if I am supposed to try > > > a patch. > > > > Thanks for doing the bsearch - it helps. > > > > There were no driver changes between 2.6.11-rc4 and 2.6.11-rc5. > > > > The only PCI change I see is > > > > --- drivers/pci/pci.c 22 Jan 2005 03:20:37 -0000 1.71 > > +++ drivers/pci/pci.c 24 Feb 2005 18:02:37 -0000 1.72 > > @@ -268,7 +268,7 @@ > > return -EIO; > > > > pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc); > > - if ((pmc & PCI_PM_CAP_VER_MASK) != 2) { > > + if ((pmc & PCI_PM_CAP_VER_MASK) > 2) { > > printk(KERN_DEBUG > > "PCI: %s has unsupported PM cap regs version (%u)\n", > > dev->slot_name, pmc & PCI_PM_CAP_VER_MASK); > > > > and you're not getting that message (are you?) > > > > I have still the problem described above with 2.6.12-rc2-mm2 and > reverting the above patch solved it. And yes, now I get many of those > > PCI: 0000:00:0b.0 has unsupported PM cap regs version (1) > PCI: 0000:00:0d.0 has unsupported PM cap regs version (1) > PCI: 0000:00:09.0 has unsupported PM cap regs version (1) > > messages. > Yes, we need to work out what's going on here. Daniel? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2) 2005-04-12 9:09 ` Andrew Morton @ 2005-04-13 19:24 ` Daniel Ritz 2005-04-13 22:41 ` Peter Baumann 0 siblings, 1 reply; 16+ messages in thread From: Daniel Ritz @ 2005-04-13 19:24 UTC (permalink / raw) To: Andrew Morton, Peter Baumann; +Cc: linux-kernel, greg On Tuesday 12 April 2005 11:09, Andrew Morton wrote: > Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> wrote: > > > > On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote: > > > Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> wrote: > > > > > > > > > > > > I'm hitting an annoying bug in kernel 2.6.11.5 > > > > > > > > Every time I _reboot_ (warmstart) my pc my two network cards won't get > > > > recognized any longer. > > > > > > > > Following error message appears on my screen: > > > > > > > > PCI: Enabling device 0000:00:0b.0 (0000 -> 0003) > > > > ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 > > > > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html > > > > 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19 > > > > PCI: Setting latency timer of device 0000:00:0b.0 to 64 > > > > *** EEPROM MAC address is invalid. > > > > 3c59x: vortex_probe1 fails. Returns -22 > > > > 3c59x: probe of 0000:00:0b.0 failed with error -22 > > > > PCI: Enabling device 0000:00:0d.0 (0000 -> 0003) > > > > ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19 > > > > 0000:00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers LK1.1.19 > > > > PCI: Setting latency timer of device 0000:00:0d.0 to 64 > > > > *** EEPROM MAC address is invalid. > > > > 3c59x: vortex_probe1 fails. Returns -22 > > > > 3c59x: probe of 0000:00:0d.0 failed with error -22 > > > > > > > > This doesn't happen with older kernels (especially with 2.6.10) and so > > > > I've done a binary search and narrowed it down to 2.6.11-rc5 where it > > > > first hits me. > > > > > > > > My config, lspci output and the dmesg output of the working and non-working > > > > version can be found at [1] > > > > > > > > Feel free to ask if any information is missing or if I am supposed to try > > > > a patch. > > > > > > Thanks for doing the bsearch - it helps. > > > > > > There were no driver changes between 2.6.11-rc4 and 2.6.11-rc5. > > > > > > The only PCI change I see is > > > > > > --- drivers/pci/pci.c 22 Jan 2005 03:20:37 -0000 1.71 > > > +++ drivers/pci/pci.c 24 Feb 2005 18:02:37 -0000 1.72 > > > @@ -268,7 +268,7 @@ > > > return -EIO; > > > > > > pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc); > > > - if ((pmc & PCI_PM_CAP_VER_MASK) != 2) { > > > + if ((pmc & PCI_PM_CAP_VER_MASK) > 2) { > > > printk(KERN_DEBUG > > > "PCI: %s has unsupported PM cap regs version (%u)\n", > > > dev->slot_name, pmc & PCI_PM_CAP_VER_MASK); > > > > > > and you're not getting that message (are you?) > > > > > > > I have still the problem described above with 2.6.12-rc2-mm2 and > > reverting the above patch solved it. And yes, now I get many of those > > > > PCI: 0000:00:0b.0 has unsupported PM cap regs version (1) > > PCI: 0000:00:0d.0 has unsupported PM cap regs version (1) > > PCI: 0000:00:09.0 has unsupported PM cap regs version (1) > > > > messages. > > > > Yes, we need to work out what's going on here. > > Daniel? yes. i already posted a debugging patch and asked to have to dmesg output. but no response. Message-Id: <200504050042.11987.daniel.ritz@gmx.ch> i see two possibilities: - it's not really writing to the PM registers but somewhere else (or it's writing some crap) - the device hates when somebody writes the current state again (yes, there is a check for this but it's useless during boot). i have a patch for this but i didn't send it until now because i really like to see the debugging output first...attached anyway... rgds -daniel ------------------ [PATCH] PCI PM: read initial state from device the PCI PM code tries not to write to the PM registers when there is no change in state. this however fails when a device is initially set up. and because some devices are broken they hate being forced to the state they are in. fix it by reading the current state from the device itself. also does some other things: - support PCI PM CAP version 3 (as defined in PCI PM Interface Spec v1.2) - add and export the function pci_get_power_state() to get it from the device - pci.h defines "4" as D3cold while probe.c uses it for unknown state - minor cleanups --- 1.151/include/linux/pci.h 2005-02-03 19:08:22 +01:00 +++ edited/include/linux/pci.h 2005-04-09 00:49:42 +02:00 @@ -501,6 +501,7 @@ #define PCI_D2 ((pci_power_t __force) 2) #define PCI_D3hot ((pci_power_t __force) 3) #define PCI_D3cold ((pci_power_t __force) 4) +#define PCI_UNKNOWN ((pci_power_t __force) 5) /* * The pci_dev structure is used to describe PCI devices. @@ -822,6 +823,7 @@ /* Power management related routines */ int pci_save_state(struct pci_dev *dev); int pci_restore_state(struct pci_dev *dev); +pci_power_t pci_get_power_state(struct pci_dev *dev); int pci_set_power_state(struct pci_dev *dev, pci_power_t state); pci_power_t pci_choose_state(struct pci_dev *dev, pm_message_t state); int pci_enable_wake(struct pci_dev *dev, pci_power_t state, int enable); --- 1.81/drivers/pci/pci.c 2005-03-03 08:17:57 +01:00 +++ edited/drivers/pci/pci.c 2005-04-09 01:02:15 +02:00 @@ -227,6 +227,28 @@ } /** + * pci_get_power_state - Gets the power state of a PCI device + * @dev: PCI device + * + * RETURN VALUE: + * pci_power_t the current state + */ +pci_power_t pci_get_power_state(struct pci_dev *dev) +{ + int pm; + u16 pmcsr; + + pm = pci_find_capability(dev, PCI_CAP_ID_PM); + if (!pm) + return PCI_UNKNOWN; + + pci_read_config_word(dev, pm + PCI_PM_CTRL, &pmcsr); + pmcsr &= PCI_PM_CTRL_STATE_MASK; + + return (pci_power_t) pmcsr; +} + +/** * pci_set_power_state - Set the power state of a PCI device * @dev: PCI device to be suspended * @state: PCI power state (D0, D1, D2, D3hot, D3cold) we're entering @@ -268,7 +290,7 @@ return -EIO; pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc); - if ((pmc & PCI_PM_CAP_VER_MASK) > 2) { + if ((pmc & PCI_PM_CAP_VER_MASK) > 3) { printk(KERN_DEBUG "PCI: %s has unsupported PM cap regs version (%u)\n", pci_name(dev), pmc & PCI_PM_CAP_VER_MASK); @@ -276,12 +298,10 @@ } /* check if this device supports the desired state */ - if (state == PCI_D1 || state == PCI_D2) { - if (state == PCI_D1 && !(pmc & PCI_PM_CAP_D1)) - return -EIO; - else if (state == PCI_D2 && !(pmc & PCI_PM_CAP_D2)) - return -EIO; - } + if (state == PCI_D1 && !(pmc & PCI_PM_CAP_D1)) + return -EIO; + else if (state == PCI_D2 && !(pmc & PCI_PM_CAP_D2)) + return -EIO; /* If we're in D3, force entire word to 0. * This doesn't affect PME_Status, disables PME_En, and @@ -830,6 +850,7 @@ EXPORT_SYMBOL(pci_assign_resource); EXPORT_SYMBOL(pci_find_parent_resource); +EXPORT_SYMBOL(pci_get_power_state); EXPORT_SYMBOL(pci_set_power_state); EXPORT_SYMBOL(pci_save_state); EXPORT_SYMBOL(pci_restore_state); --- 1.80/drivers/pci/probe.c 2005-02-03 03:21:51 +01:00 +++ edited/drivers/pci/probe.c 2005-04-09 00:57:21 +02:00 @@ -563,7 +563,7 @@ dev->devfn, dev->vendor, dev->device, class, dev->hdr_type); /* "Unknown power state" */ - dev->current_state = 4; + dev->current_state = PCI_UNKNOWN; /* Early fixups, before probing the BARs */ pci_fixup_device(pci_fixup_early, dev); @@ -608,6 +608,9 @@ pci_name(dev), class, dev->hdr_type); dev->class = PCI_CLASS_NOT_DEFINED; } + + /* get the real power state from the device */ + dev->current_state = pci_get_power_state(dev); /* We found a fine healthy device, go go go... */ return 0; ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2) 2005-04-13 19:24 ` Daniel Ritz @ 2005-04-13 22:41 ` Peter Baumann 2005-04-14 17:40 ` Daniel Ritz 0 siblings, 1 reply; 16+ messages in thread From: Peter Baumann @ 2005-04-13 22:41 UTC (permalink / raw) To: Daniel Ritz; +Cc: Andrew Morton, Peter Baumann, linux-kernel, greg On Wed, Apr 13, 2005 at 09:24:04PM +0200, Daniel Ritz wrote: > On Tuesday 12 April 2005 11:09, Andrew Morton wrote: > > Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> wrote: > > > > > > On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote: > > > > Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> wrote: > > > > > > > > > > > > > > > I'm hitting an annoying bug in kernel 2.6.11.5 > > > > > > > > > > Every time I _reboot_ (warmstart) my pc my two network cards won't get > > > > > recognized any longer. > > > > > > > > > > Following error message appears on my screen: > > > > > > > > > > PCI: Enabling device 0000:00:0b.0 (0000 -> 0003) > > > > > ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 > > > > > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html > > > > > 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19 > > > > > PCI: Setting latency timer of device 0000:00:0b.0 to 64 > > > > > *** EEPROM MAC address is invalid. > > > > > 3c59x: vortex_probe1 fails. Returns -22 > > > > > 3c59x: probe of 0000:00:0b.0 failed with error -22 > > > > > PCI: Enabling device 0000:00:0d.0 (0000 -> 0003) > > > > > ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19 > > > > > 0000:00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers LK1.1.19 > > > > > PCI: Setting latency timer of device 0000:00:0d.0 to 64 > > > > > *** EEPROM MAC address is invalid. > > > > > 3c59x: vortex_probe1 fails. Returns -22 > > > > > 3c59x: probe of 0000:00:0d.0 failed with error -22 > > > > > > > > > > This doesn't happen with older kernels (especially with 2.6.10) and so > > > > > I've done a binary search and narrowed it down to 2.6.11-rc5 where it > > > > > first hits me. > > > > > > > > > > My config, lspci output and the dmesg output of the working and non-working > > > > > version can be found at [1] > > > > > > > > > > Feel free to ask if any information is missing or if I am supposed to try > > > > > a patch. > > > > > > > > Thanks for doing the bsearch - it helps. > > > > > > > > There were no driver changes between 2.6.11-rc4 and 2.6.11-rc5. > > > > > > > > The only PCI change I see is > > > > > > > > --- drivers/pci/pci.c 22 Jan 2005 03:20:37 -0000 1.71 > > > > +++ drivers/pci/pci.c 24 Feb 2005 18:02:37 -0000 1.72 > > > > @@ -268,7 +268,7 @@ > > > > return -EIO; > > > > > > > > pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc); > > > > - if ((pmc & PCI_PM_CAP_VER_MASK) != 2) { > > > > + if ((pmc & PCI_PM_CAP_VER_MASK) > 2) { > > > > printk(KERN_DEBUG > > > > "PCI: %s has unsupported PM cap regs version (%u)\n", > > > > dev->slot_name, pmc & PCI_PM_CAP_VER_MASK); > > > > > > > > and you're not getting that message (are you?) > > > > > > > > > > I have still the problem described above with 2.6.12-rc2-mm2 and > > > reverting the above patch solved it. And yes, now I get many of those > > > > > > PCI: 0000:00:0b.0 has unsupported PM cap regs version (1) > > > PCI: 0000:00:0d.0 has unsupported PM cap regs version (1) > > > PCI: 0000:00:09.0 has unsupported PM cap regs version (1) > > > > > > messages. > > > > > > > Yes, we need to work out what's going on here. > > > > Daniel? > > yes. i already posted a debugging patch and asked to have to dmesg output. > but no response. Message-Id: <200504050042.11987.daniel.ritz@gmx.ch> > > i see two possibilities: > - it's not really writing to the PM registers but somewhere else (or it's > writing some crap) > - the device hates when somebody writes the current state again > (yes, there is a check for this but it's useless during boot). i have > a patch for this but i didn't send it until now because i really like > to see the debugging output first...attached anyway... > > rgds > -daniel > > ------------------ > > [PATCH] PCI PM: read initial state from device > > the PCI PM code tries not to write to the PM registers when there is no change > in state. this however fails when a device is initially set up. and because > some devices are broken they hate being forced to the state they are in. fix > it by reading the current state from the device itself. also does some other > things: > - support PCI PM CAP version 3 (as defined in PCI PM Interface Spec v1.2) > - add and export the function pci_get_power_state() to get it from the device > - pci.h defines "4" as D3cold while probe.c uses it for unknown state > - minor cleanups > [patch snipped] I tried your patch with 2.6.12-rc2-mm3 (did not apply cleanly, I have applied one hunk per hand) and here is a diff of the dmesg of a working/non-working version. If I should try something else, then tell me and I will do. The full dmesg output can be obtained from http://wwwcip.informatik.uni-erlangen.de/~siprbaum/kernel/2.6.12-rc2-mm3_firstboot.txt http://wwwcip.informatik.uni-erlangen.de/~siprbaum/kernel/2.6.12-rc2-mm3_secondboot.txt --- 2.6.12-rc2-mm3_firstboot.txt 2005-04-14 00:31:13.000000000 +0200 +++ 2.6.12-rc2-mm3_secondboot.txt 2005-04-14 00:31:13.000000000 +0200 @@ -47,7 +47,7 @@ ide_setup: ide4=noprobe ide_setup: ide5=noprobe PID hash table entries: 2048 (order: 11, 32768 bytes) -Detected 1537.101 MHz processor. +Detected 1537.644 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) @@ -149,11 +149,21 @@ ACPI: No ACPI bus support for floppy.0 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) +PCI: Enabling device 0000:00:0b.0 (0000 -> 0003) ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html -0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xac00. Vers LK1.1.19 +0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19 +PCI: Setting latency timer of device 0000:00:0b.0 to 64 +*** EEPROM MAC address is invalid. +3c59x: vortex_probe1 fails. Returns -22 +3c59x: probe of 0000:00:0b.0 failed with error -22 +PCI: Enabling device 0000:00:0d.0 (0000 -> 0003) ACPI: PCI Interrupt 0000:00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19 -0000:00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xb000. Vers LK1.1.19 +0000:00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers LK1.1.19 +PCI: Setting latency timer of device 0000:00:0d.0 to 64 +*** EEPROM MAC address is invalid. +3c59x: vortex_probe1 fails. Returns -22 +3c59x: probe of 0000:00:0d.0 failed with error -22 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx HPT370A: IDE controller at PCI slot 0000:00:08.0 @@ -408,13 +418,11 @@ ACPI: No ACPI bus support for 4-0:1.0 parport: PnPBIOS parport detected. parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA] -ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 -ACPI: PCI Interrupt 0000:00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19 ACPI: CPU0 (power states: C1[C1]) ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] ACPI: Fan [FAN] (on) -ACPI: Thermal Zone [THRM] (42 C) +ACPI: Thermal Zone [THRM] (40 C) lp0: using parport0 (interrupt-driven). Bluetooth: Core ver 2.7 NET: Registered protocol family 31 Gruss, Peter Baumann ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2) 2005-04-13 22:41 ` Peter Baumann @ 2005-04-14 17:40 ` Daniel Ritz 2005-04-15 6:50 ` Peter Baumann [not found] ` <20050415064352.GA16475@faui00u.informatik.uni-erlangen.de> 0 siblings, 2 replies; 16+ messages in thread From: Daniel Ritz @ 2005-04-14 17:40 UTC (permalink / raw) To: Peter Baumann; +Cc: Andrew Morton, linux-kernel, greg On Thursday 14 April 2005 00:41, Peter Baumann wrote: > On Wed, Apr 13, 2005 at 09:24:04PM +0200, Daniel Ritz wrote: > > On Tuesday 12 April 2005 11:09, Andrew Morton wrote: > > > Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> wrote: > > > > > > > > On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote: > > > > > Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> wrote: > > > > > > > > > > > > > > > > > > I'm hitting an annoying bug in kernel 2.6.11.5 > > > > > > > > > > > > Every time I _reboot_ (warmstart) my pc my two network cards won't get > > > > > > recognized any longer. > > > > > > > > > > > > Following error message appears on my screen: > > > > > > > > > > > > PCI: Enabling device 0000:00:0b.0 (0000 -> 0003) > > > > > > ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 > > > > > > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html > > > > > > 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19 > > > > > > PCI: Setting latency timer of device 0000:00:0b.0 to 64 > > > > > > *** EEPROM MAC address is invalid. > > > > > > 3c59x: vortex_probe1 fails. Returns -22 > > > > > > 3c59x: probe of 0000:00:0b.0 failed with error -22 > > > > > > PCI: Enabling device 0000:00:0d.0 (0000 -> 0003) > > > > > > ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19 > > > > > > 0000:00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers LK1.1.19 > > > > > > PCI: Setting latency timer of device 0000:00:0d.0 to 64 > > > > > > *** EEPROM MAC address is invalid. > > > > > > 3c59x: vortex_probe1 fails. Returns -22 > > > > > > 3c59x: probe of 0000:00:0d.0 failed with error -22 > > > > > > > > > > > > This doesn't happen with older kernels (especially with 2.6.10) and so > > > > > > I've done a binary search and narrowed it down to 2.6.11-rc5 where it > > > > > > first hits me. > > > > > > > > > > > > My config, lspci output and the dmesg output of the working and non-working > > > > > > version can be found at [1] > > > > > > > > > > > > Feel free to ask if any information is missing or if I am supposed to try > > > > > > a patch. > > > > > > > > > > Thanks for doing the bsearch - it helps. > > > > > > > > > > There were no driver changes between 2.6.11-rc4 and 2.6.11-rc5. > > > > > > > > > > The only PCI change I see is > > > > > > > > > > --- drivers/pci/pci.c 22 Jan 2005 03:20:37 -0000 1.71 > > > > > +++ drivers/pci/pci.c 24 Feb 2005 18:02:37 -0000 1.72 > > > > > @@ -268,7 +268,7 @@ > > > > > return -EIO; > > > > > > > > > > pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc); > > > > > - if ((pmc & PCI_PM_CAP_VER_MASK) != 2) { > > > > > + if ((pmc & PCI_PM_CAP_VER_MASK) > 2) { > > > > > printk(KERN_DEBUG > > > > > "PCI: %s has unsupported PM cap regs version (%u)\n", > > > > > dev->slot_name, pmc & PCI_PM_CAP_VER_MASK); > > > > > > > > > > and you're not getting that message (are you?) > > > > > > > > > > > > > I have still the problem described above with 2.6.12-rc2-mm2 and > > > > reverting the above patch solved it. And yes, now I get many of those > > > > > > > > PCI: 0000:00:0b.0 has unsupported PM cap regs version (1) > > > > PCI: 0000:00:0d.0 has unsupported PM cap regs version (1) > > > > PCI: 0000:00:09.0 has unsupported PM cap regs version (1) > > > > > > > > messages. > > > > > > > > > > Yes, we need to work out what's going on here. > > > > > > Daniel? > > > > yes. i already posted a debugging patch and asked to have to dmesg output. > > but no response. Message-Id: <200504050042.11987.daniel.ritz@gmx.ch> > > > > i see two possibilities: > > - it's not really writing to the PM registers but somewhere else (or it's > > writing some crap) > > - the device hates when somebody writes the current state again > > (yes, there is a check for this but it's useless during boot). i have > > a patch for this but i didn't send it until now because i really like > > to see the debugging output first...attached anyway... > > > > rgds > > -daniel > > > > ------------------ > > > > [PATCH] PCI PM: read initial state from device > > > > the PCI PM code tries not to write to the PM registers when there is no change > > in state. this however fails when a device is initially set up. and because > > some devices are broken they hate being forced to the state they are in. fix > > it by reading the current state from the device itself. also does some other > > things: > > - support PCI PM CAP version 3 (as defined in PCI PM Interface Spec v1.2) > > - add and export the function pci_get_power_state() to get it from the device > > - pci.h defines "4" as D3cold while probe.c uses it for unknown state > > - minor cleanups > > > > [patch snipped] > > I tried your patch with 2.6.12-rc2-mm3 (did not apply cleanly, I have > applied one hunk per hand) and here is a diff of the dmesg of a > working/non-working version. If I should try something else, then tell > me and I will do. > > The full dmesg output can be obtained from > > http://wwwcip.informatik.uni-erlangen.de/~siprbaum/kernel/2.6.12-rc2-mm3_firstboot.txt > http://wwwcip.informatik.uni-erlangen.de/~siprbaum/kernel/2.6.12-rc2-mm3_secondboot.txt > could you apply this debuggin patch instead and send me the dmsg output plus output from lspci, lspci -vvvn. also please send me a hexdump from /proc/bus/pci/00/0b.0 i think i'm having some 3coms around so maybe i can reprocude :) rgds -daniel --- 1.81/drivers/pci/pci.c 2005-03-03 08:17:57 +01:00 +++ edited/drivers/pci/pci.c 2005-04-05 00:37:13 +02:00 @@ -268,7 +268,7 @@ return -EIO; pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc); - if ((pmc & PCI_PM_CAP_VER_MASK) > 2) { + if ((pmc & PCI_PM_CAP_VER_MASK) > 3) { printk(KERN_DEBUG "PCI: %s has unsupported PM cap regs version (%u)\n", pci_name(dev), pmc & PCI_PM_CAP_VER_MASK); @@ -287,15 +287,19 @@ * This doesn't affect PME_Status, disables PME_En, and * sets PowerState to 0. */ - if (dev->current_state >= PCI_D3hot) + printk("PCI: %s pmc: %04x, current_state, pmcsr: %08x", pci_name(dev), pmc, dev->current_state); + if (dev->current_state >= PCI_D3hot) { pmcsr = 0; - else { + printk("0"); + } else { pci_read_config_word(dev, pm + PCI_PM_CTRL, &pmcsr); + printk("%04x", pmcsr); pmcsr &= ~PCI_PM_CTRL_STATE_MASK; pmcsr |= state; } /* enter specified state */ + printk(", new: %04x\n", pmcsr); pci_write_config_word(dev, pm + PCI_PM_CTRL, pmcsr); /* Mandatory power management transition delays */ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2) 2005-04-14 17:40 ` Daniel Ritz @ 2005-04-15 6:50 ` Peter Baumann [not found] ` <20050415064352.GA16475@faui00u.informatik.uni-erlangen.de> 1 sibling, 0 replies; 16+ messages in thread From: Peter Baumann @ 2005-04-15 6:50 UTC (permalink / raw) To: linux-kernel; +Cc: Peter Baumann, Andrew Morton, greg On Thu, Apr 14, 2005 at 07:40:52PM +0200, Daniel Ritz wrote: > could you apply this debuggin patch instead and send me the dmsg output > plus output from lspci, lspci -vvvn. also please send me a hexdump from > /proc/bus/pci/00/0b.0 > > i think i'm having some 3coms around so maybe i can reprocude :) > > rgds > -daniel > > --- 1.81/drivers/pci/pci.c 2005-03-03 08:17:57 +01:00 > +++ edited/drivers/pci/pci.c 2005-04-05 00:37:13 +02:00 > @@ -268,7 +268,7 @@ > return -EIO; > > pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc); > - if ((pmc & PCI_PM_CAP_VER_MASK) > 2) { > + if ((pmc & PCI_PM_CAP_VER_MASK) > 3) { > printk(KERN_DEBUG > "PCI: %s has unsupported PM cap regs version (%u)\n", > pci_name(dev), pmc & PCI_PM_CAP_VER_MASK); > @@ -287,15 +287,19 @@ > * This doesn't affect PME_Status, disables PME_En, and > * sets PowerState to 0. > */ > - if (dev->current_state >= PCI_D3hot) > + printk("PCI: %s pmc: %04x, current_state, pmcsr: %08x", pci_name(dev), pmc, dev->current_state); > + if (dev->current_state >= PCI_D3hot) { > pmcsr = 0; > - else { > + printk("0"); > + } else { > pci_read_config_word(dev, pm + PCI_PM_CTRL, &pmcsr); > + printk("%04x", pmcsr); > pmcsr &= ~PCI_PM_CTRL_STATE_MASK; > pmcsr |= state; > } > > /* enter specified state */ > + printk(", new: %04x\n", pmcsr); > pci_write_config_word(dev, pm + PCI_PM_CTRL, pmcsr); > > /* Mandatory power management transition delays */ > I send Daniel the info privately, but just for your convenience, I put it also on my homepage [1]. -Peter [1]: http://wwwcip.informatik.uni-erlangen.de/~siprbaum/kernel/ ...._1.txt = working version (first boot) ...._2.txt = non working version (second boot) ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <20050415064352.GA16475@faui00u.informatik.uni-erlangen.de>]
* Re: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2) [not found] ` <20050415064352.GA16475@faui00u.informatik.uni-erlangen.de> @ 2005-04-17 20:26 ` Daniel Ritz 2005-04-18 22:19 ` Peter Baumann 0 siblings, 1 reply; 16+ messages in thread From: Daniel Ritz @ 2005-04-17 20:26 UTC (permalink / raw) To: Peter Baumann; +Cc: Andrew Morton, linux-kernel, greg On Friday 15 April 2005 08:43, Peter Baumann wrote: > On Thu, Apr 14, 2005 at 07:40:52PM +0200, Daniel Ritz wrote: > > > > could you apply this debuggin patch instead and send me the dmsg output > > plus output from lspci, lspci -vvvn. also please send me a hexdump from > > /proc/bus/pci/00/0b.0 > > > > i think i'm having some 3coms around so maybe i can reprocude :) > > > > rgds > > -daniel > > > > --- 1.81/drivers/pci/pci.c 2005-03-03 08:17:57 +01:00 > > +++ edited/drivers/pci/pci.c 2005-04-05 00:37:13 +02:00 > > @@ -268,7 +268,7 @@ > > return -EIO; > > > > pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc); > > - if ((pmc & PCI_PM_CAP_VER_MASK) > 2) { > > + if ((pmc & PCI_PM_CAP_VER_MASK) > 3) { > > printk(KERN_DEBUG > > "PCI: %s has unsupported PM cap regs version (%u)\n", > > pci_name(dev), pmc & PCI_PM_CAP_VER_MASK); > > @@ -287,15 +287,19 @@ > > * This doesn't affect PME_Status, disables PME_En, and > > * sets PowerState to 0. > > */ > > - if (dev->current_state >= PCI_D3hot) > > + printk("PCI: %s pmc: %04x, current_state, pmcsr: %08x", pci_name(dev), pmc, dev->current_state); for the record: i messed up that printk, but anyway... > > + if (dev->current_state >= PCI_D3hot) { > > pmcsr = 0; > > - else { > > + printk("0"); > > + } else { > > pci_read_config_word(dev, pm + PCI_PM_CTRL, &pmcsr); > > + printk("%04x", pmcsr); > > pmcsr &= ~PCI_PM_CTRL_STATE_MASK; > > pmcsr |= state; > > } > > > > /* enter specified state */ > > + printk(", new: %04x\n", pmcsr); > > pci_write_config_word(dev, pm + PCI_PM_CTRL, pmcsr); > > > > /* Mandatory power management transition delays */ > > > > I applied this one (just for the record, the offsets weren't correct for > 2.6.12-rc2-mm3, but it applied cleanly) (it was against mainline, not -mm) > > Attached is the info you asked for. > > ...1.txt = first boot (working) > ...2.txt = second boot (not working) > > -Peter > from your dmesg: PCI: 0000:00:0b.0 pmc: 7601, current_state, pmcsr: 000000040, new: 0000 ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xac00. Vers LK1.1.19 PCI: 0000:00:0b.0 pmc: 7601, current_state, pmcsr: 000000000000, new: 0003 so the device is sent to D3 right after it is up. nice. and second boot: PCI: 0000:00:0b.0 pmc: 7601, current_state, pmcsr: 000000040, new: 0000 PCI: Enabling device 0000:00:0b.0 (0000 -> 0003) ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19 PCI: Setting latency timer of device 0000:00:0b.0 to 64 *** EEPROM MAC address is invalid. 3c59x: vortex_probe1 fails. Returns -22 3c59x: probe of 0000:00:0b.0 failed with error -22 to me it looks like during the second boot the device is in D3 and has troubles coming out of it. unfortunatley that is not made visible by the debugging patch. a hexdump of the device in a second boot without loading the 3c59x driver would tell us... the diff in the hexdumps of the config space proves that the device is programmed wrong: --- hexdump-2.6.12-rc2-mm3-withdebugpatch_1.txt 2005-04-17 21:27:28.000000000 +0200 +++ hexdump-2.6.12-rc2-mm3-withdebugpatch_2.txt 2005-04-17 21:27:32.000000000 +0200 @@ -1,7 +1,7 @@ -0000000 10b7 9055 0007 0210 0024 0200 2008 0000 -0000010 ac01 0000 2000 e800 0000 0000 0000 0000 +0000000 10b7 9055 0003 0210 0024 0200 4000 0000 +0000010 0001 0000 0000 0000 0000 0000 0000 0000 so the I/O ports and the iomem are not set! 0000020 0000 0000 0000 0000 0000 0000 10b7 9055 -0000030 0000 0000 00dc 0000 0000 0000 010a 0a0a +0000030 0000 0000 00dc 0000 0000 0000 0100 0a0a 0000040 0000 0000 0000 0000 0000 0000 0000 0000 0000050 0000 0000 0040 0000 0000 0000 0000 0000 0000060 0000 0000 0000 0000 0000 0000 0000 0000 but to make it short: i think it's a driver bug. the device doesn't seem to be correctly reprogrammed when it is in D3 initially. and then it shouldn't be put into D3 during the first boot. so please try with the attached patch. rgds -daniel PS: does somebody have a datasheet of a 3com chip around? i could need one. ----- [PATCH] 3c59x: only put the device into D3 when we're actually using WOL Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> --- 1.77/drivers/net/3c59x.c 2005-03-03 06:00:42 +01:00 +++ edited/drivers/net/3c59x.c 2005-04-17 22:17:19 +02:00 @@ -1581,7 +1581,8 @@ if (VORTEX_PCI(vp)) { pci_set_power_state(VORTEX_PCI(vp), PCI_D0); /* Go active */ - pci_restore_state(VORTEX_PCI(vp)); + if (vp->pm_state_valid) + pci_restore_state(VORTEX_PCI(vp)); pci_enable_device(VORTEX_PCI(vp)); } @@ -2741,6 +2742,7 @@ outl(0, ioaddr + DownListPtr); if (final_down && VORTEX_PCI(vp)) { + vp->pm_state_valid = 1; pci_save_state(VORTEX_PCI(vp)); acpi_set_WOL(dev); } @@ -3243,9 +3245,10 @@ outw(RxEnable, ioaddr + EL3_CMD); pci_enable_wake(VORTEX_PCI(vp), 0, 1); + + /* Change the power state to D3; RxEnable doesn't take effect. */ + pci_set_power_state(VORTEX_PCI(vp), PCI_D3hot); } - /* Change the power state to D3; RxEnable doesn't take effect. */ - pci_set_power_state(VORTEX_PCI(vp), PCI_D3hot); } ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2) 2005-04-17 20:26 ` Daniel Ritz @ 2005-04-18 22:19 ` Peter Baumann 2005-04-19 17:47 ` Daniel Ritz 0 siblings, 1 reply; 16+ messages in thread From: Peter Baumann @ 2005-04-18 22:19 UTC (permalink / raw) To: Daniel Ritz; +Cc: Peter Baumann, Andrew Morton, linux-kernel, greg On Sun, Apr 17, 2005 at 10:26:43PM +0200, Daniel Ritz wrote: > from your dmesg: > PCI: 0000:00:0b.0 pmc: 7601, current_state, pmcsr: 000000040, new: 0000 > ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html > 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xac00. Vers LK1.1.19 > PCI: 0000:00:0b.0 pmc: 7601, current_state, pmcsr: 000000000000, new: 0003 > > so the device is sent to D3 right after it is up. nice. > > and second boot: > PCI: 0000:00:0b.0 pmc: 7601, current_state, pmcsr: 000000040, new: 0000 > PCI: Enabling device 0000:00:0b.0 (0000 -> 0003) > ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html > 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19 > PCI: Setting latency timer of device 0000:00:0b.0 to 64 > *** EEPROM MAC address is invalid. > 3c59x: vortex_probe1 fails. Returns -22 > 3c59x: probe of 0000:00:0b.0 failed with error -22 > > to me it looks like during the second boot the device is in D3 and has > troubles coming out of it. unfortunatley that is not made visible by the > debugging patch. a hexdump of the device in a second boot without > loading the 3c59x driver would tell us... > > the diff in the hexdumps of the config space proves that the device > is programmed wrong: > --- hexdump-2.6.12-rc2-mm3-withdebugpatch_1.txt 2005-04-17 21:27:28.000000000 +0200 > +++ hexdump-2.6.12-rc2-mm3-withdebugpatch_2.txt 2005-04-17 21:27:32.000000000 +0200 > @@ -1,7 +1,7 @@ > -0000000 10b7 9055 0007 0210 0024 0200 2008 0000 > -0000010 ac01 0000 2000 e800 0000 0000 0000 0000 > +0000000 10b7 9055 0003 0210 0024 0200 4000 0000 > +0000010 0001 0000 0000 0000 0000 0000 0000 0000 > > so the I/O ports and the iomem are not set! > > 0000020 0000 0000 0000 0000 0000 0000 10b7 9055 > -0000030 0000 0000 00dc 0000 0000 0000 010a 0a0a > +0000030 0000 0000 00dc 0000 0000 0000 0100 0a0a > 0000040 0000 0000 0000 0000 0000 0000 0000 0000 > 0000050 0000 0000 0040 0000 0000 0000 0000 0000 > 0000060 0000 0000 0000 0000 0000 0000 0000 0000 > > but to make it short: i think it's a driver bug. the device doesn't seem to be > correctly reprogrammed when it is in D3 initially. and then it shouldn't be > put into D3 during the first boot. so please try with the attached patch. > > rgds > -daniel > > PS: does somebody have a datasheet of a 3com chip around? i could need one. > > ----- > > [PATCH] 3c59x: only put the device into D3 when we're actually using WOL > > Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> > > --- 1.77/drivers/net/3c59x.c 2005-03-03 06:00:42 +01:00 > +++ edited/drivers/net/3c59x.c 2005-04-17 22:17:19 +02:00 > @@ -1581,7 +1581,8 @@ > > if (VORTEX_PCI(vp)) { > pci_set_power_state(VORTEX_PCI(vp), PCI_D0); /* Go active */ > - pci_restore_state(VORTEX_PCI(vp)); > + if (vp->pm_state_valid) > + pci_restore_state(VORTEX_PCI(vp)); > pci_enable_device(VORTEX_PCI(vp)); > } > > @@ -2741,6 +2742,7 @@ > outl(0, ioaddr + DownListPtr); > > if (final_down && VORTEX_PCI(vp)) { > + vp->pm_state_valid = 1; > pci_save_state(VORTEX_PCI(vp)); > acpi_set_WOL(dev); > } > @@ -3243,9 +3245,10 @@ > outw(RxEnable, ioaddr + EL3_CMD); > > pci_enable_wake(VORTEX_PCI(vp), 0, 1); > + > + /* Change the power state to D3; RxEnable doesn't take effect. */ > + pci_set_power_state(VORTEX_PCI(vp), PCI_D3hot); > } > - /* Change the power state to D3; RxEnable doesn't take effect. */ > - pci_set_power_state(VORTEX_PCI(vp), PCI_D3hot); > } > The patch solved it. Thank you for your help. -Peter Baumann ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2) 2005-04-18 22:19 ` Peter Baumann @ 2005-04-19 17:47 ` Daniel Ritz 2005-04-24 1:37 ` Andrew Morton 0 siblings, 1 reply; 16+ messages in thread From: Daniel Ritz @ 2005-04-19 17:47 UTC (permalink / raw) To: Peter Baumann; +Cc: Andrew Morton, linux-kernel, greg, Jeff Garzik On Tuesday 19 April 2005 00:19, Peter Baumann wrote: > On Sun, Apr 17, 2005 at 10:26:43PM +0200, Daniel Ritz wrote: > > from your dmesg: > > PCI: 0000:00:0b.0 pmc: 7601, current_state, pmcsr: 000000040, new: 0000 > > ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 > > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html > > 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xac00. Vers LK1.1.19 > > PCI: 0000:00:0b.0 pmc: 7601, current_state, pmcsr: 000000000000, new: 0003 > > > > so the device is sent to D3 right after it is up. nice. > > > > and second boot: > > PCI: 0000:00:0b.0 pmc: 7601, current_state, pmcsr: 000000040, new: 0000 > > PCI: Enabling device 0000:00:0b.0 (0000 -> 0003) > > ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19 > > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html > > 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19 > > PCI: Setting latency timer of device 0000:00:0b.0 to 64 > > *** EEPROM MAC address is invalid. > > 3c59x: vortex_probe1 fails. Returns -22 > > 3c59x: probe of 0000:00:0b.0 failed with error -22 > > > > to me it looks like during the second boot the device is in D3 and has > > troubles coming out of it. unfortunatley that is not made visible by the > > debugging patch. a hexdump of the device in a second boot without > > loading the 3c59x driver would tell us... > > > > the diff in the hexdumps of the config space proves that the device > > is programmed wrong: > > --- hexdump-2.6.12-rc2-mm3-withdebugpatch_1.txt 2005-04-17 21:27:28.000000000 +0200 > > +++ hexdump-2.6.12-rc2-mm3-withdebugpatch_2.txt 2005-04-17 21:27:32.000000000 +0200 > > @@ -1,7 +1,7 @@ > > -0000000 10b7 9055 0007 0210 0024 0200 2008 0000 > > -0000010 ac01 0000 2000 e800 0000 0000 0000 0000 > > +0000000 10b7 9055 0003 0210 0024 0200 4000 0000 > > +0000010 0001 0000 0000 0000 0000 0000 0000 0000 > > > > so the I/O ports and the iomem are not set! > > > > 0000020 0000 0000 0000 0000 0000 0000 10b7 9055 > > -0000030 0000 0000 00dc 0000 0000 0000 010a 0a0a > > +0000030 0000 0000 00dc 0000 0000 0000 0100 0a0a > > 0000040 0000 0000 0000 0000 0000 0000 0000 0000 > > 0000050 0000 0000 0040 0000 0000 0000 0000 0000 > > 0000060 0000 0000 0000 0000 0000 0000 0000 0000 > > > > but to make it short: i think it's a driver bug. the device doesn't seem to be > > correctly reprogrammed when it is in D3 initially. and then it shouldn't be > > put into D3 during the first boot. so please try with the attached patch. > > > > rgds > > -daniel > > > > PS: does somebody have a datasheet of a 3com chip around? i could need one. > > > > ----- > > > > [PATCH] 3c59x: only put the device into D3 when we're actually using WOL > > > > Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> > > > > --- 1.77/drivers/net/3c59x.c 2005-03-03 06:00:42 +01:00 > > +++ edited/drivers/net/3c59x.c 2005-04-17 22:17:19 +02:00 > > @@ -1581,7 +1581,8 @@ > > > > if (VORTEX_PCI(vp)) { > > pci_set_power_state(VORTEX_PCI(vp), PCI_D0); /* Go active */ > > - pci_restore_state(VORTEX_PCI(vp)); > > + if (vp->pm_state_valid) > > + pci_restore_state(VORTEX_PCI(vp)); > > pci_enable_device(VORTEX_PCI(vp)); > > } > > > > @@ -2741,6 +2742,7 @@ > > outl(0, ioaddr + DownListPtr); > > > > if (final_down && VORTEX_PCI(vp)) { > > + vp->pm_state_valid = 1; > > pci_save_state(VORTEX_PCI(vp)); > > acpi_set_WOL(dev); > > } > > @@ -3243,9 +3245,10 @@ > > outw(RxEnable, ioaddr + EL3_CMD); > > > > pci_enable_wake(VORTEX_PCI(vp), 0, 1); > > + > > + /* Change the power state to D3; RxEnable doesn't take effect. */ > > + pci_set_power_state(VORTEX_PCI(vp), PCI_D3hot); > > } > > - /* Change the power state to D3; RxEnable doesn't take effect. */ > > - pci_set_power_state(VORTEX_PCI(vp), PCI_D3hot); > > } > > > > The patch solved it. Thank you for your help. ok, nice to see it working. andrew, could you add it to -mm please? [ adding jeff to cc: because it's a network driver :) ] thanks, rgds -daniel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2) 2005-04-19 17:47 ` Daniel Ritz @ 2005-04-24 1:37 ` Andrew Morton 0 siblings, 0 replies; 16+ messages in thread From: Andrew Morton @ 2005-04-24 1:37 UTC (permalink / raw) To: daniel.ritz; +Cc: Peter.B.Baumann, linux-kernel, greg, jgarzik Daniel Ritz <daniel.ritz@gmx.ch> wrote: > > > > --- 1.77/drivers/net/3c59x.c 2005-03-03 06:00:42 +01:00 > > > +++ edited/drivers/net/3c59x.c 2005-04-17 22:17:19 +02:00 > ... > > The patch solved it. Thank you for your help. > > ok, nice to see it working. > andrew, could you add it to -mm please? Sure will. Thanks for working that out. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2005-04-24 1:42 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-23 12:24 [Bug] invalid mac address after rebooting (kernel 2.6.11.5) Peter Baumann
2005-03-24 2:52 ` Andrew Morton
2005-03-24 11:01 ` Peter Baumann
2005-03-24 11:07 ` Andrew Morton
2005-03-24 11:54 ` Peter Baumann
2005-04-03 13:40 ` Daniel Drake
2005-04-12 8:59 ` [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2) Peter Baumann
2005-04-12 9:09 ` Andrew Morton
2005-04-13 19:24 ` Daniel Ritz
2005-04-13 22:41 ` Peter Baumann
2005-04-14 17:40 ` Daniel Ritz
2005-04-15 6:50 ` Peter Baumann
[not found] ` <20050415064352.GA16475@faui00u.informatik.uni-erlangen.de>
2005-04-17 20:26 ` Daniel Ritz
2005-04-18 22:19 ` Peter Baumann
2005-04-19 17:47 ` Daniel Ritz
2005-04-24 1:37 ` Andrew Morton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox