/proc/interrupts vs. /proc/stat (and reality)
Hi, my /proc/interrupts doesn't show all the interrupts that have been used, /proc/stat (and hence procinfo) does. All of the devices work without problems. % cat /proc/interrupts /proc/stat && procinfo CPU0 0: 476919 XT-PIC timer 1: 12333 XT-PIC keyboard 2: 0 XT-PIC cascade 3:221 XT-PIC 5: 8388 XT-PIC soundblaster 7: 0 XT-PIC parport0 8: 67 XT-PIC rtc 10: 53 XT-PIC advansys, ncr53c8xx 11: 35704 XT-PIC HiSax 12: 49384 XT-PIC PS/2 Mouse 14: 29 XT-PIC ide0 15: 39616 XT-PIC ide1 NMI: 0 ERR: 0 cpu 25315 461 35481 415662 cpu0 25315 461 35481 415662 page 331823 243999 swap 2 0 intr 622904 476919 12333 0 221 160 8388 30 0 67 0 53 35704 49384 0 29 39616 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 disk_io: (2,0):(34,34,37,0,0) (3,0):(5,5,10,0,0) (8,0):(8,8,16,0,0) ctxt 2581888 btime 988535311 processes 1291 Linux 2.4.4-pre4 (root@elmicha) (gcc 2.95.3 20010315 ) #2 1CPU [elmicha.(none)] Memory: TotalUsedFree Shared Buffers Cached Mem:384352 319980 64372 04816 137528 Swap: 939752 260 939492 Bootup: Sun Apr 29 11:08:31 2001Load average: 0.05 0.13 0.10 6/103 1292 user : 0:04:13.15 5.3% page in : 331823 nice : 0:00:04.61 0.1% page out: 243999 system: 0:05:54.82 7.4% swap in :2 idle : 1:09:16.62 87.2% swap out:0 uptime: 1:19:29.19 context : 2581892 irq 0:476920 timer irq 7: 0 parport0 irq 1: 12333 keyboard irq 8:67 rtc irq 2: 0 cascade [4] irq 10:53 advansys, ncr53c8xx irq 3: 221 irq 11: 35704 HiSax irq 4: 160 irq 12: 49384 PS/2 Mouse irq 5: 8388 soundblaster irq 14:29 ide0 irq 6:30 irq 15: 39616 ide1 So IRQ 3 doesn't know it's getting serviced by the serial module, IRQ 4 and IRQ 6 don't show in /proc/interrupts (and I've used both serial ports and the floppy before), only in /proc/stat. This is an Athlon 700 on a Gigabyte 7IXE (Irongate/Viper), gcc-2.95.3 compiled 2.4.4-pre4. Some lines from .config: CONFIG_MK7=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y Have I done something wrong? Should I send more info? Regards... Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Serial ports rearranged in 2.6.22?
Hi, until 2.6.21, I had the normal assignments for ttyS0 and ttyS1: 00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A With 2.6.22 I get the names <-> ports/irqs the other way around: 00:08: ttyS0 at I/O 0x2f8 (irq = 3) is a 16550A 00:09: ttyS1 at I/O 0x3f8 (irq = 4) is a 16550A Is this supposed to be that way? Should we reassign these names with udev? udev-114 doesn't seem to have built-in rules to assign the traditional names. Or could it be related to some brokeness in my BIOS (ACPI/PNP)? I'm using the 8250_pnp module (and it's the same with builtin serial modules). I made sure that I did not accidentally change the BIOS settings for the serial ports. I'm using Gentoo, but on the lirc list was a Fedora user with the same symptoms. Regards... Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serial ports rearranged in 2.6.22?
Yinghai Lu wrote: > On 8/10/07, Michael Mauch <[EMAIL PROTECTED]> wrote: > > Hi, > > > > until 2.6.21, I had the normal assignments for ttyS0 and ttyS1: > > > > 00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A > > 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A > > > > With 2.6.22 I get the names <-> ports/irqs the other way around: > > > > 00:08: ttyS0 at I/O 0x2f8 (irq = 3) is a 16550A > > 00:09: ttyS1 at I/O 0x3f8 (irq = 4) is a 16550A > > > > Is this supposed to be that way? Should we reassign these names with > > udev? udev-114 doesn't seem to have built-in rules to assign the > > traditional names. > > > > Or could it be related to some brokeness in my BIOS (ACPI/PNP)? > > > > I'm using the 8250_pnp module (and it's the same with builtin serial > > modules). I made sure that I did not accidentally change the BIOS > > settings for the serial ports. > > > > I'm using Gentoo, but on the lirc list was a Fedora user with the same > > symptoms. > > http://lkml.org/lkml/2007/7/25/455 Thanks - I applied that patch and the names are back to normal again: 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A Regards... Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serial ports rearranged in 2.6.22?
Bjorn Helgaas wrote: > On Saturday 11 August 2007 09:49:25 am Michael Mauch wrote: > > Yinghai Lu wrote: > > > > > On 8/10/07, Michael Mauch <[EMAIL PROTECTED]> wrote: > > > > > > > > With 2.6.22 I get the names <-> ports/irqs the other way around: > > > > > > > > 00:08: ttyS0 at I/O 0x2f8 (irq = 3) is a 16550A > > > > 00:09: ttyS1 at I/O 0x3f8 (irq = 4) is a 16550A > > > > ... > > > http://lkml.org/lkml/2007/7/25/455 > > > > Thanks - I applied that patch and the names are back to normal again: > > > > 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A > > 00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A > > Just FYI, the patch Yinghai mentioned above was experimental, and > we decided it was the wrong solution. > > For 2.6.22, the easiest workaround is to boot with the > "legacy_serial.force" option. Ah, ok, and load the legacy_serial module. Going from built-in serial to modules I was already challenged to find serial_core, 8250, 8250_pnp and/or 8250_pci (the help in "make menuconfig" does not seem to show the help that is written in the Kconfig file for 8250_pnp and 8250_pci). > For 2.6.23, we reverted my patch that caused the names to be swapped: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=57d4810ea0d9ca58a7bcc1336607f0cede0a2abf Thanks for the information - I wondered how you decided. What about 2.6.22.x? Or should the distro kernels use that revert patch for their stable 2.6.22 kernels? Regards... Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Stable identification of identical USB hardware
Joerg Pommnitz wrote:
> I want to be able to distinguish between two (or more) mostly
> identical USB serial devices. The devices in question are UMTS modems.
> AFAIK they are identical except for the SIM card and the point of
> attachment. Externally the cards are CardBus devices with an integrated
> USB host adapter. The actual UMTS device is (internally) connected to
> the USB host adapter.
> If I have to cardbus sockets, how do I get from what I know ("the card
> is in socket 0") to "I have to talk to ttyUSB2 to talk to the card"? I
> suspect I have to follow the thread from /sys/bus/pci to
> /sys/bus/usb/devices, but how exactly?
You should be able to distinguish the devices with udev. Have a look at
http://www.reactivated.net/writing_udev_rules.html
If that doesn't help, I would like to propose that you ask again in
the de.comp.os.unix.linux.hardware or comp.os.linux.hardware newsgroups.
Regards...
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
Uwe Bugla wrote: > Andrey's path however (i. e. copying his attached version of loop.c into the > 2.6.22-rc2 kernel tree) led to: > > a. an incompilable kernel > b. endless messages trying to compile loop.c going like this (just a part of > them - not complete anyway!): > > drivers/block/loop.c:1350: error: stray '\240' in program That's the fault of one of your MUAs, that decided to convert a normal space into a "no break space". With GNU sed you could use sed -i 's/\xa0/\x20/g' loop.c to replace these back. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] time locale in gen_initramfs_list.sh
Florian Fainelli wrote: > This is true. According to GNU fileutils changelog, the nearest Changelog > message regarding this option is : > > 2004-11-19 Alfred M. Szmidt <[EMAIL PROTECTED]> > >* src/ls.c (usage): Clarified description of --no-group (-G), >--human-readable (-h), --inode (-i), --size (-s), --time, >and --time-style. It's also possible to overwrite that TIME_STYLE variable (which is responsible for the format change), like so LC_ALL=C TIME_STYLE=locale ls -l ... Regards... Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wake up from a serial port
Guennadi Liakhovetski wrote: > Enable wakeup from serial ports, make it run-time configurable over sysfs, > e.g., > > echo enabled > /sys/devices/platform/serial8250.0/tty/ttyS0/power/wakeup Interesting, but how does that work from a user's/hardware perspective? Do I have to pull DSR/RI to +12V? Can I use one of the other pins to get these +12V (i.e. a switch and a resistor to shorten these pins is enough)? And probably in the BIOS I have to enable "wake on modem ring" (or something similar)? Regards... Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
