Re: Interrupts issues
Volker wrote:
On 12/23/-58 20:59, Carlos A. M. dos Santos wrote:
On Fri, Sep 19, 2008 at 12:04 PM, Benjie Chen <[EMAIL PROTECTED]> wrote:
Hi FreeBSD hackers:
I have two Dell workstations that I recently added FreeBSD 6.2 on. One
is a Precision T3400, one is an Inspiron 530. Nothing fancy. Installed
FBsd. Everything else is fine except both machines have interrupt
storm issues: one core (both dual core) is 100% servicing interrupts.
On the Precision, it's irq20 atapci, on Inspiron it's irq19 uhci. The
other core is fine and both machines run well otherwise.
I saw several recent posts on the net about some of these issues and
did not find a resolution. It seems unlikely that it's just a ata or
usb issue since both machines happen to have the same problem.
Any thoughts?
Please provide the output of "dmesg" after a boot in verbose mode.
This may help the maintainers to understand your problem and give you
additional instructions.
Do you have any special reason to use FreeBSD 6.2? It is a rather old
version, ...
6.2 has already been EOL'd in May.
___
I need to join the club, my machine starts doing interrupt storms after
an uptime of ${random} on the IRQ19 (atapci0) thingy. Next time I'll
boot the machine I'll try to make it a verbose boot. It's a production
machine which cannot restart on demand ofcourse :)
Note: First the problems occured much more, this was because the usb
interfaces on the machine co-existed with the atapci0 interface,
after disabling usb on the system, it took a lot longer to trigger
the interrupt storm (50 days if I recall correctly).
Cheers
remko
Regular dmesg:
Copyright (c) 1992-2008 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-PRERELEASE #7: Thu Sep 18 09:53:16 CEST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/x
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ (2799.99-MHz
K8-class CPU)
Origin = "AuthenticAMD" Id = 0x40f33 Stepping = 3
Features=0x178bfbff
Features2=0x2001
AMD Features=0xea500800
AMD Features2=0x1f
Cores per package: 2
usable memory = 2103840768 (2006 MB)
avail memory = 2028867584 (1934 MB)
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
This module (opensolaris) contains code covered by the
Common Development and Distribution License (CDDL)
see http://opensolaris.org/os/licensing/opensolaris_license/
ioapic0 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 7df0 (3) failed
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
pcib0: port 0xcf8-0xcff on acpi0
pci0: on pcib0
pcib1: at device 1.0 on pci0
pci1: on pcib1
vgapci0: port 0xc000-0xc0ff mem
0xfc00-0xfdff,0xfe9f-0xfe9f,0xfe80-0xfe8f irq 18
at device 5.0 on pci1
pci1: at device 5.2 (no driver attached)
pcib2: at device 7.0 on pci0
pci2: on pcib2
re0: Ethernet> port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf irq 19 at device
0.0 on pci2
re0: turning off MSI enable bit.
re0: Chip rev. 0x3800
re0: MAC rev. 0x
miibus0: on re0
rgephy0: PHY 1 on miibus0
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
re0: Ethernet address: 00:1d:92:b1:a3:2f
re0: [FILTER]
atapci0: port
0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f
mem 0xfe7ff800-0xfe7ffbff irq 22 at device 18.0 on pci0
atapci0: [ITHREAD]
atapci0: AHCI Version 01.10 controller with 4 ports detected
ata2: on atapci0
ata2: [ITHREAD]
ata3: on atapci0
ata3: [ITHREAD]
ata4: on atapci0
ata4: [ITHREAD]
ata5: on atapci0
ata5: [ITHREAD]
pci0: at device 19.0 (no driver attached)
pci0: at device 19.1 (no driver attached)
pci0: at device 19.2 (no driver attached)
pci0: at device 19.3 (no driver attached)
pci0: at device 19.4 (no driver attached)
pci0: at device 19.5 (no driver attached)
pci0: at device 20.0 (no driver attached)
atapci1: port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0
ata0: on atapci1
ata0: [ITHREAD]
isab0: at device 20.3 on pci0
isa0: on isab0
pcib3: at device 20.4 on pci0
pci3: on pcib3
acpi_button0: on acpi0
sio0: configured irq 3 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 3 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on
acpi0
sio0: type 16550A
sio0: [FILTER]
atkbdc0: port 0x60,0x64 irq 1 on acpi0
atkbd0: irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [I
smbus & i2c: why i2c is not enabled on ich?
Any reason why i2c mode in not enable in ichsmb? [EMAIL PROTECTED]:0:31:3:class=0x0c0500 card=0x82d81043 chip=0x266a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB (ICH6) SMBus Controller' class = serial bus subclass = SMBus [EMAIL PROTECTED]:~/eeebsd >sudo pciconf -rb pci0:0:31:3: 0x40 01 [EMAIL PROTECTED]:~/eeebsd >sudo ./scan_smbus res: 0 slave = 0x44 data = res: 0 slave = 0x50 data = res: 0 slave = 0x69 data = res: 0 slave = 0xC4 data = res: 0 slave = 0xD0 data = res: 0 slave = 0xE9 data = [EMAIL PROTECTED]:~/eeebsd >sudo pciconf -wb pci0:0:31:3: 0x40 5 [EMAIL PROTECTED]:~/eeebsd >sudo pciconf -rb pci0:0:31:3: 0x40 05 [EMAIL PROTECTED]:~/eeebsd >sudo ./scan_smbus res: 0 slave = 0x44 data = FF FF FF FF res: 0 slave = 0x50 data = 0A 60 40 00 05 30 45 00 82 08 00 00 0C 04 res: 0 slave = 0x69 data = FF F7 00 00 01 0F 07 E0 18 46 1B 24 D8 63 00 res: 0 slave = 0xC4 data = FF FF FF FF res: 0 slave = 0xD0 data = 0A 60 40 00 05 30 45 00 82 08 00 00 0C 04 res: 0 slave = 0xE9 data = FF F7 00 00 01 0F 07 E0 18 46 1B 24 D8 63 00 FYI this is on an asus eeepc. -- bye, P. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kgdb's add-kld broken on amd64
In article <[EMAIL PROTECTED]> you write: >On Wednesday 17 September 2008 03:51:02 pm Navdeep Parhar wrote: >> Hello John, >> >> The patch did NOT fix the problem. Read on for more >> >> On Wed, Sep 17, 2008 at 8:31 AM, John Baldwin <[EMAIL PROTECTED]> wrote: >> > On Tuesday 16 September 2008 04:07:46 pm Navdeep Parhar wrote: >> >> Hello everyone, >> >> >> >> The add-kld command in kgdb does not work as expected on amd64 >> >> (I'm using a recent HEAD, problem may affect others too). It uses >> >> the same address for all sections: >> >> >> >> (kgdb) add-kld if_cxgb.ko >> >> add symbol table from file "/boot/kernel/if_cxgb.ko" at >> >> .text_addr = 0x81022000 >> >> .rodata_addr = 0x81022000 >> >> .rodata.str1.8_addr = 0x81022000 >> >> .rodata.str1.1_addr = 0x81022000 >> >> set_modmetadata_set_addr = 0x81022000 >> >> set_sysctl_set_addr = 0x81022000 >> >> set_sysinit_set_addr = 0x81022000 >> >> set_sysuninit_set_addr = 0x81022000 >> >> .data_addr = 0x81022000 >> >> .bss_addr = 0x81022000 >> >> (y or n) >> >> >> >> This is not correct. The .text section's address is OK but the >> >> others are not. >> >> >> >> The problem seems to be that all amd64 kernel objects have VMA set >> >> to 0 for all sections. add_section() in gnu/usr.bin/gdb/kgdb/kld.c >> >> uses this VMA to adjust the address of the section: >> >> >> >> address = asi->base_addr + bfd_get_section_vma(bfd, sect); >> >> >> >> objdump -h shows that the userland objects on amd64 and all >> >> objects (kernel + userland) on i386 set VMA. It is only the >> >> kernel objects on amd64 that have VMA = 0. (sample output from >> >> amd64 and i386 machines appended at the end) >> >> >> >> For the time being I've patched kgdb to consider the file offset >> >> and not the VMA while calculating the section address. It seems >> >> to work but is probably not the right way to fix the problem. >> >> >> >> Any thoughts? >> > >> > Hmm, I wonder if this is because on amd64 modules are .o's rather >than .so's. >> > It is. File offset isn't quite right. Instead, the way >> > sys/kern/link_elf_obj.c works is that it just loads the PROGBITS (text, >code, >> > etc.) and NOBITS (bss) sections in the order they are in the file and >> > concatenates them. So, the relocation logic in kgdb will need to be >updated >> > to recognize a .o vs .so and apply that algorithm for .o files. >> > >> > Actually, what I've done is to replace the home-rolled section relocation >> > stuff with the gdb primitives that the solib code in gdb uses. It works >here >> > on i386, and hopefully this will fix this as this is how the sharedlibrary >> > kld stuff is doing the relocations: >> >> I had to modify the patch a bit as add-kld -> build_section_table() -> >xfree() >> was a bad free and led to bus errors or segv: >> >> - struct section_table *sections, *sections_end, *s; >> + struct section_table *sections = NULL, *sections_end = NULL, *s; >> >> After fixing that, add-kld still wouldn't pick up the correct >> addresses: >> >> (kgdb) add-kld if_cxgb.ko >> add symbol table from file "/boot/kernel/if_cxgb.ko" at >> .text_addr = 0x81022000 >> .rodata_addr = 0x81022000 >> .rodata.str1.8_addr = 0x81022000 >> .rodata.str1.1_addr = 0x81022000 >> set_modmetadata_set_addr = 0x81022000 >> set_sysctl_set_addr = 0x81022000 >> set_sysinit_set_addr = 0x81022000 >> set_sysuninit_set_addr = 0x81022000 >> .data_addr = 0x81022000 >> .bss_addr = 0x81022000 >> >> With the patch the section relocation is still taking place based >> on the VMA (which is 0 for amd64 modules as I pointed out >> earlier). So the behaviour is no different than before. If I >> read the code right, each section's addr is calculated as: >> >> load_kld -> build_section_table -> add_to_section_table >> >> This sets it to bfd_section_vma(abfd, asect), which is no good >> for amd64 kernel modules. > >Well, this means gdb can't handle loading .o's, though I guess that is to be >expected. :( Even if I fix add-kld there's probably no way I can easily fix >the sharedlibrary stuff w/o ripping gdb itself up a bunch. I haven't looked at what the gdb patch exactly does, but I was able to load klds the old way on amd64 using a patched asf(8) as posted here: http://lists.freebsd.org/pipermail/freebsd-amd64/2008-May/011062.html Better than nothing I guess... :) Juergen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: smbus & i2c: why i2c is not enabled on ich?
On Sun, Sep 21, 2008 at 01:55:45PM +0200, Paolo Pisati wrote: > > Any reason why i2c mode in not enable in ichsmb? Because the controller is a SMB controller and not a I2C one. SMB is more specific than I2C in that it defines complete I2C sequences. With SMB you don't have the individual control over all I2C phases. You can do SMB with an I2C controller, but you can't do raw I2C with an SMB controller. Use SMB to address your devices - SMB is good enough to handle most I2C cases. > [EMAIL PROTECTED]:0:31:3:class=0x0c0500 card=0x82d81043 chip=0x266a8086 > rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801FB (ICH6) SMBus Controller' > class = serial bus > subclass = SMBus > > [EMAIL PROTECTED]:~/eeebsd >sudo pciconf -rb pci0:0:31:3: 0x40 > 01 > [EMAIL PROTECTED]:~/eeebsd >sudo ./scan_smbus > res: 0 slave = 0x44 data = > res: 0 slave = 0x50 data = > res: 0 slave = 0x69 data = > res: 0 slave = 0xC4 data = > res: 0 slave = 0xD0 data = > res: 0 slave = 0xE9 data = > [EMAIL PROTECTED]:~/eeebsd >sudo pciconf -wb pci0:0:31:3: 0x40 5 > [EMAIL PROTECTED]:~/eeebsd >sudo pciconf -rb pci0:0:31:3: 0x40 > 05 > [EMAIL PROTECTED]:~/eeebsd >sudo ./scan_smbus > res: 0 slave = 0x44 data = FF FF FF FF > res: 0 slave = 0x50 data = 0A 60 40 00 05 30 45 00 82 08 00 00 0C 04 > res: 0 slave = 0x69 data = FF F7 00 00 01 0F 07 E0 18 46 1B 24 D8 63 00 > res: 0 slave = 0xC4 data = FF FF FF FF > res: 0 slave = 0xD0 data = 0A 60 40 00 05 30 45 00 82 08 00 00 0C 04 > res: 0 slave = 0xE9 data = FF F7 00 00 01 0F 07 E0 18 46 1B 24 D8 63 00 > > FYI this is on an asus eeepc. > -- > bye, > P. > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- B.Walter <[EMAIL PROTECTED]> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
