"pci=routeirq" on IBM Thinkpad A20m Type 2628-3au fixes wireless card in cardbus/pcmcia slot
pci=routeirq makes my wireless lan card in a cardbus/pcmcia slot work. I'm posting these are requested in the dmesg. (below are lspci and dmesg, more available by request) Here's the lspci: 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) Flags: bus master, medium devsel, latency 64 Memory at f800 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 1.0 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 128 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 2000-2fff Memory behind bridge: f420-f5ff Prefetchable memory behind bridge: 3000-300f 00:02.0 CardBus bridge: Texas Instruments PCI1450 (rev 03) Subsystem: IBM Thinkpad T20/T22/A21m Flags: bus master, medium devsel, latency 168, IRQ 5 Memory at 5000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=02, subordinate=05, sec-latency=176 Memory window 0: 2000-23fff000 (prefetchable) Memory window 1: 2400-27fff000 I/O window 0: 1400-14ff I/O window 1: 1c00-1cff 16-bit legacy interface ports at 0001 00:02.1 CardBus bridge: Texas Instruments PCI1450 (rev 03) Subsystem: IBM Thinkpad T20/T22/A21m Flags: bus master, medium devsel, latency 168, IRQ 9 Memory at 5010 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=06, subordinate=09, sec-latency=176 Memory window 0: 2800-2bfff000 (prefetchable) Memory window 1: 2c00-2000 I/O window 0: 3000-30ff I/O window 1: 3400-34ff 16-bit legacy interface ports at 0001 00:03.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 09) Subsystem: Intel Corporation EtherExpress PRO/100+ MiniPCI Flags: bus master, medium devsel, latency 66, IRQ 10 Memory at f412 (32-bit, non-prefetchable) [size=4K] I/O ports at 1800 [size=64] Memory at f410 (32-bit, non-prefetchable) [size=128K] [virtual] Expansion ROM at 3010 [disabled] [size=1M] Capabilities: [dc] Power Management version 2 00:03.1 Serial controller: Xircom Mini-PCI V.90 56k Modem (prog-if 02 [16550]) Subsystem: Intel Corporation Unknown device 2408 Flags: medium devsel, IRQ 10 I/O ports at 1840 [size=8] Memory at f4121000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 00:05.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24/30 [CrystalClear SoundFusion Audio Accelerator] (rev 01) Subsystem: IBM ThinkPad A20m Flags: bus master, slow devsel, latency 64, IRQ 5 Memory at f4122000 (32-bit, non-prefetchable) [size=4K] Memory at f400 (32-bit, non-prefetchable) [size=1M] Capabilities: [40] Power Management version 2 00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) Flags: bus master, medium devsel, latency 0 00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 64 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at 1850 [size=16] 00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI]) Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at 1860 [size=32] 00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) Flags: medium devsel, IRQ 9 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64) (prog-if 00 [VGA]) Subsystem: IBM ThinkPad A20m/A21m Flags: bus master, stepping, medium devsel, latency 66, IRQ 5 Memory at f500 (32-bit, non-prefetchable) [size=16M] I/O ports at 2000 [size=256] Memory at f420 (32-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at 3000 [disabled] [size=128K] Capabilities: [50] AGP version 1.0 Capabilities: [5c] Power Management version 2 dmesg: Linux version 2.6.22-1-686 (Debian 2.6.22-3) ([EMAIL PROTECTED]) (gcc version 4.1.3 20070718 (prerelease) (Debian 4.1.2-14)) #1 SMP Sun Jul 29 14:37:42 UTC 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 13ff (usable) BIOS-e820: 13ff - 13ffec00 (ACPI data) BIOS-e820: 13ffec00 - 1400 (ACPI NVS) BIOS-e820: fff8 - 0001 (reserved) 0MB HIGHMEM available. 319MB LOWMEM available. Entering add_act
Re: PCI Quirk / Hidden Bus Report
I also have the same type message in my dmesg from a Dell Latitude D820 with the latest BIOS: PCI: Probing PCI hardware (bus 00) PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO PCI quirk: region 1080-10bf claimed by ICH6 GPIO PCI: Transparent bridge - :00:1e.0 PCI: Bus #04 (-#07) is hidden behind transparent bridge #03 (-#04) (try 'pci=assign-busses') Please report the result to linux-kernel to fix this permanently ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP02._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PXP0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP04._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11) ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *4 ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 11) *3 ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 *7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay Full dmesg attached. Adrian Bunk wrote: Bernhard? cu Adrian On Wed, Jul 18, 2007 at 11:33:55PM -0400, pat-lkml wrote: I received: PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0a) (try 'pci=assign-busses') Please report the result to linux-kernel to fix this permanently in my dmesg in 2.6.22, and am reporting it. Context of message follows. Full dmesg output available on request. This is a Clevo d900t laptop motherboard, and everything works perfectly on it. Pat Erley -- ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 checking TSC synchronization [CPU#0 -> CPU#1]: passed. Brought up 2 CPUs migration_cost=22 NET: Registered protocol family 16 EISA bus registered ACPI: bus type pci registered PCI: BIOS Bug: MCFG area at e000 is not E820-reserved PCI: Not using MMCONFIG. PCI: PCI BIOS revision 2.10 entry at 0xfd951, last bus=10 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO PCI quirk: region 1180-11bf claimed by ICH6 GPIO PCI: Transparent bridge - :00:1e.0 PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0a) (try 'pci=assign-busses') Please report the result to linux-kernel to fix this permanently ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEG_._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 10) *11 ACPI: PCI Interrupt Link [LNKB] (IRQs 11) *10 ACPI: PCI Interrupt Link [LNKC] (IRQs 10) *5 ACPI: PCI Interrupt Link [LNKD] (IRQs 11) *10 ACPI: PCI Interrupt Link [LNKE] (IRQs *10) ACPI: PCI Interrupt Link [LNKF] (IRQs *11) ACPI: PCI Interrupt Link [LNKG] (IRQs 10) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs *11) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: bus type pnp registered pnp: PnP ACPI: found 12 devices ACPI: ACPI bus type pnp unregistered SCSI subsystem initialized libata version 2.21 loaded. PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report Time: tsc clocksource has been installed. - 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/ dmesg-latitude-d820.txt.gz Description: GNU Zip compressed data
Re: GIT Packages for Debian Etch
Christoph Lameter wrote: On Tue, 19 Jun 2007, Thomas Glanzmann wrote: The other choice that we developers usually make is to run either testing or unstable. "stable" is a synonym for obsolete ;-). I'm just not going to let this go. Stable is synonymous with, well ummm, "stable." That means that I don't have 3000 changes a month, it's secure and the unexpected doesn't happen. It means I can write a lecture explaining how git works. ...do updates... then expect my lecture to still work the next day. It means writing local shell scripts and expecting them to work until the NEXT stable release without changes. It means knowing what things WILL break if and when I do go to the next version. Stable is a CHOICE not a punishment. -- Jeffrey Hundstad PS. Running unstable on my laptop... and running stable on my servers. - 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: filesystem benchmarking fun
Jeff Garzik wrote: Jan Engelhardt wrote: On May 16 2007 10:42, Chris Mason wrote: For example, I'll pick on xfs for a minute. compilebench shows the default FS you get from mkfs.xfs is pretty slow for untarring a bunch of kernel trees. I suppose you used 'nobarrier'? [ http://lkml.org/lkml/2006/5/19/33 ] Shouldn't that option be renamed to 'corrupt_my_data'? ;-) Perhaps maybe "my_power_never_fails". Jeff - 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/ - 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: Corrupt XFS -Filesystems on new Hardware and Kernel
Oliver Joa wrote: I also often get a sata-bus-reset with the kernels 2.6.19.2 and 2.6.20.2. What can I do to find the problem? I think about to change from xfs to ext2 but the filesystemcheck every 30 mounts lasts a long time. Do you have any Idea? In this whole message I can only help on this point. Switching to ext2 will not help. You've got *something* wrong with YOUR setup. I have used the kernels you mention in VERY large environments with excellent and stable results. You need to find out what's up with the sata-bus-reset problem. It won't do *me* any good but people who can fix your problem will want the entire .config and dmesg to even guess about what is going on with *your* situation. For more info on XFS. This is a pretty nice FAQ: http://oss.sgi.com/projects/xfs/faq.html -- Jeffrey Hundstad - 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] sched: rsdl improvements
Artur Skawina wrote: Con Kolivas wrote: Note no interactive boost idea here. Patch is for 2.6.21-rc4-mm1. I have not spent the time trying to bring other bases in sync. I've tried RSDLv.31+this on 2.6.20.3 as i'm not tracking -mm. Further improve the deterministic nature of the RSDL cpu scheduler and make the rr_interval tunable. By only giving out priority slots to tasks at the current runqueue's prio_level or below we can make the cpu allocation not altered by accounting issues across major_rotation periods. This makes the cpu allocation and latencies more deterministic, and decreases maximum latencies substantially. This change removes the possibility that tasks can get bursts of cpu activity which can favour towards interactive tasks but also favour towards cpu bound tasks which happen to wait on other activity (such as I/O) and is a net gain. I'm not sure this is going in the right direction... I'm writing this while compiling a kernel w/ "nice -20 make -j2" and X is almost Did you mean "nice -20"? If so, that should have slowed X quite a bit. Try "nice 19" instead. nice(1): Run COMMAND with an adjusted niceness, which affects process scheduling. With no COMMAND, print the current niceness. Nicenesses range from -20 (most favorable scheduling) to 19 (least favorable). - 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: Multiple instances of program sharing same text segment ?
Keep in mind that while the text of the program IS SHARED any configuration file that is then loaded into ram after the execution IS NOT SHARED. BTW you can find out what is shared and not by taking a look at the proc files: # ps auxwww | grep emacs | grep -v grep # -- find the pids user 21529 0.2 0.3 16784 7560 pts/11 S+ 14:27 0:00 xemacs -nw user 21549 0.2 0.3 16784 7548 pts/12 S+ 14:27 0:00 xemacs -nw # cat /proc/21529/maps |grep xemacs | grep "r-xp" # -- find the mapped text executable 08048000-081f5000 r-xp 08:02 201672393 /usr/bin/xemacs-21.4.19-nomule # cat /proc/21549/maps |grep xemacs | grep "r-xp" # -- find the mapped text executable 08048000-081f5000 r-xp 08:02 201672393 /usr/bin/xemacs-21.4.19-nomule #ls -li /usr/bin/xemacs-21.4.19-nomule # -- confirm that 201672393 is the inode we're looking at. 201672393 -rwxr-xr-x 1 root root 1800764 2006-11-03 11:11 /usr/bin/xemacs-21.4.19-nomule Jeremy Fitzhardinge wrote: Ravinandan Arakali (rarakali) wrote: I note that do_exec calls do_mmap to map the executable file to memory. But not sure what happens(w.r.t text sharing) when another instance of the program is invoked. BTW, this is 2.6.10. Yes, they will be shared. As far as the rest of the kernel is concerned, an mmap is an mmap is an mmap, and the pages will be shared. J - 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/ - 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: 2.6.21-rc3-mm1 RSDL results
Mark Lord wrote: Mmm.. when it's good, it's *really* good. My desktop feels snappier and all of that. No noticeable jerkiness of windows/scrolling, which I *do* observe with the stock scheduler. But when it's bad, it stinks. Like when a "make -j2" kernel rebuild is happening in a background window Would you please do that same "make -j2" niced. Tell us how that feels. -- Jeffrey Hundstad - 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: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
Greg KH wrote: On Mon, Mar 05, 2007 at 07:59:50AM -0500, Theodore Tso wrote: Ok, how about the following patch. Is it acceptable to everyone? thanks, greg k-h --- init/Kconfig | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- gregkh-2.6.orig/init/Kconfig +++ gregkh-2.6/init/Kconfig @@ -290,8 +290,17 @@ config SYSFS_DEPRECATED that belong to a class, back into the /sys/class heirachy, in order to support older versions of udev. - If you are using a distro that was released in 2006 or later, - it should be safe to say N here. + If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora + release from 2007 or later, it should be safe to say N here. + + If you are using Debian or other distros that are slow to + update HAL, please say Y here. + + If you have any problems with devices not being found properly + from userspace programs, and this option is disabled, say Y + here. + + If you are unsure about this at all, say Y. config RELAY bool "Kernel->user space relay support (formerly relayfs)" Since it appears you're trying to offend people with this patch, it would seem appropriate to call someone's mother a "bad" name. This may be in the style guide; perhaps I should submit a patch. -- Jeffrey Hundstad PS: Humor (really!) relax. - 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: SATA-performance: Linux vs. FreeBSD
Arjan van de Ven wrote: The problem is: FreeBSD is fast, but lacks of some special drivers. Linux has all drivers but access to harddisk is unpredictable and thus unreliable! What can I do?? there's several tunables you can do; 1) increase /sys/block//queue/nr_requests the linux default is on the low side 2) investigate other elevators; cfq is great for interactive use but not so great for max throughput. you can do this by echo'ing "deadline" into /sys/block//scheduler I'd suggest trying the noop scheduler with your ram based devices. I don't see why these devices would need clever scheduling. ...but prove me wrong if you will. I haven't tested this. echo noop > /sys/block//queue/scheduler If you don't need journaling EXT2 might be a good choice. But, I'd also like to re-iterate the XFS filesystem recommendation given several times now as well. There are many tunables that /may/ help during filesystem creation. Block size (-b) set to it's maximum would prob. help. If you're sure you can not encounter power issues: mount -t xfs -o nobarrier /dev/ /mount-point Here's some more general reading for ya: Troubleshooting Linux Performance Issues: http://www.phptr.com/articles/article.asp?p=481867&seqNum=2&rl=1 -- Jeffrey Hundstad - 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: ownership/permissions of cpio initrd
Jan Engelhardt wrote: It appears to not be standard with fedora for sure... but while it origiginally was/is a Debian package it looks like there is source if you'd like to build it on other systems. It was originally designed to tackle the exact problem you are confronting. See: http://freshmeat.net/projects/fakeroot/ About: Fakeroot runs a command in an environment were it appears to have root privileges for file manipulation, by setting LD_PRELOAD to a library with alternative versions of getuid(), stat(), etc. This is useful for allowing users to create archives (tar, ar, .deb .rpm etc.) with files in them with root permissions/ownership. Without fakeroot one would have to have root privileges to create the constituent files of the archives with the correct permissions and ownership, and then pack them up, or one would have to construct the archives directly, without using the archiver. Ugh that sounds even more than a hack. At least for one-user archives, I guess nobody at Debian knows that tar has a --user and --group option. -`J' ...It also let's you mknod and friends, and let's you set permissions to files to more than just ONE user. The whole point of the commands is to let you make distribution files without root access. Of course you can fake all of this with a special archiver command I'm just throwing out options. $ fakeroot # mkdir root # mkdir root/dev/ # mknod root/dev/null c 1 3 # mknod root/dev/sda1 b 8 1 # chown root.disk root/dev/sda1 # cd root # tar cvf ../root.tar ./ # exit $ tar tvf root.tar drwxr-xr-x root/root 0 2006-12-05 14:54 ./ drwxr-xr-x root/root 0 2006-12-05 14:54 ./dev/ crw-r--r-- root/root 1,3 2006-12-05 14:54 ./dev/null brw-r--r-- root/disk 8,1 2006-12-05 14:54 ./dev/sda1 -- Jeffrey Hundstad - 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: ownership/permissions of cpio initrd
It appears to not be standard with fedora for sure... but while it origiginally was/is a Debian package it looks like there is source if you'd like to build it on other systems. It was originally designed to tackle the exact problem you are confronting. See: http://freshmeat.net/projects/fakeroot/ About: Fakeroot runs a command in an environment were it appears to have root privileges for file manipulation, by setting LD_PRELOAD to a library with alternative versions of getuid(), stat(), etc. This is useful for allowing users to create archives (tar, ar, .deb .rpm etc.) with files in them with root permissions/ownership. Without fakeroot one would have to have root privileges to create the constituent files of the archives with the correct permissions and ownership, and then pack them up, or one would have to construct the archives directly, without using the archiver. Horst H. von Brand wrote: Jeffrey Hundstad <[EMAIL PROTECTED]> wrote: You can also use fakeroot(1). I think that is a debianism... not here on Fedora. - 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: ownership/permissions of cpio initrd
You can also use fakeroot(1). Start fakeroot. Change all of your permissions as you see fit. make your cpio exit fakeroot. Horst H. von Brand wrote: Marty Leisner <[EMAIL PROTECTED]> wrote: I'm working on an embedded system with the 2.6 kernel -- cpio initrd was a new feature I'm looking at (and very welcome). The major advantage I see is you don't have MAKE a filesystem on the build host (doing cross development). So you don't have to be root. But its "useful" to change permissions/ownership of the initrd files at times... Since a cpio is just a userspace created string of bits, I suppose you can apply a set of ownership/permissions to files IN the archive by playing with the bits... The easy way out is to unpack the initrd, fix permissions, and repack. That requires root, though (it creates devices). Does such a tool exist? Comments? Seems very useful in order to avoid being root... I'd use sudo(1) + specially cooked commands to unpack/pack an initrd. It is a bit more work, but gives you extra flexibility (i.e., not just futzing around with permissions, can also add/replace/edit/rename/delete files, ... using bog standard tools). - 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: la la la la ... swappiness
Hello, Please forgive me if this is naive. It seems that you could recompile your tar and patch commands to use the POSIX_FADVISE(2) feature with the POSIX_FADV_NOREUSE flags. It seems these would cause the tar and patch commands to not clutter the page cache at all. It'd be nice to be able to make a wrapper out of this kind of like the fakeroot(1) command like such as: nocachesuck tar xvfz kernel.tar.gz ya know what I mean? -- Jeffrey Hundstad - 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] i386 No-Idle-Hz aka Dynamic-Ticks 3
Con Kolivas wrote: This is the dynamic ticks patch for i386 as written by Tony Lindgen <[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>. Patch for 2.6.13-rc5 There were a couple of things that I wanted to change so here is an updated version. This code should have stabilised enough for general testing now. The sysfs interface was moved to its own directory in /sys/devices/system/dyn_tick and split into separate files to enable/disable dynamic ticks and usage of apic on the fly. It makes sense to enable dynamic ticks and usage of apic by default if they're actually built into the kernel so that is now done. I am successfully running the dynamic tick patch on an old IBM ThinkPad A22m. When I enable the APIC support console beeps, you know bash -c 'echo -e "\a"', takes a REALLY long time to finish. I'm assuming this is a badly written program and not a kernel problem. Correct? BTW: how do you know what HZ your machine is running at? -- Jeffrey Hundstad - 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/
Unable to handle kernel paging request at virtual address ffffe000 - in linux-2.6.12.2
task=cdbf40a0) Stack: cc8c4000 c0102a27 b23996e0 0001 0001 b7f32e9c b2167418 00a8 007b 007b 00a8 e410 0073 0246 b21673fc 007b Call Trace: [] sysenter_past_esp+0x54/0x75 Code: ff ff 21 e0 8b 00 c7 00 00 00 00 00 8b 44 24 10 83 c4 14 5b 5e 5f 5d c3 8d b6 00 00 00 00 8d bc 27 00 00 00 00 55 b8 00 e0 ff ff <21> e0 57 56 53 83 ec 24 8b 00 8b 54 24 3c 8b 6c 24 38 8b 80 54 -- Jeffrey Hundstad - 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: journaled filesystems -- known instability; Was: XFS: inode with st_mode == 0
Stephen C. Tweedie wrote: Hi, On Mon, 2005-01-17 at 21:31, Jeffrey Hundstad wrote: For more of this look up subjects: Bad things happening to journaled filesystem machines Oops in kjournald That seems to have been due to the xattr problems recently fixed in Linus's tree. The xattr race was allowing one process to delete an unshared xattr block while another was trying to share it, and the journaling code was getting upset when the second process then tried to commit the now-deleted block. Thanks for the update. I wonder if there are several problems. Alan Cox claimed that there was a fix in linux-2.6.10-ac10 that might alleviate the problem. On linux-2.6.10-ac10 I've got one machine that's been up for 6 days now that would never last more then 1 before. On the other hand I have one machine that did die after two days. Does linux-2.6.11-rc2 have both the linux-2.6.10-ac10 fix and the xattr problem fixed? If so, I'll test there. -- Jeffrey Hundstad - 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/
journaled filesystems -- known instability; Was: XFS: inode with st_mode == 0
For more of this look up subjects: Bad things happening to journaled filesystem machines Oops in kjournald and from author: Anders Saaby I also can't keep a recent 2.6 or 2.6*-ac* kernel up more than a few hours on a machine under real load. Perhaps us folks with the problem need to talk to the powers who be to come up with a strategy to make a report they can use. My guess is we're not sending something that can be used. -- jeffrey hundstad Jakob Oestergaard wrote: On Sun, Jan 16, 2005 at 01:51:12PM +, Christoph Hellwig wrote: On Fri, Jan 14, 2005 at 07:23:09PM +0100, Jakob Oestergaard wrote: So apart from the general well known instability problems that will occur when you actually start *using* the system, there should be no What known instabilities? Where should I begin? ;) Most of the following have already been posted to LKML - primarily by Anders ([EMAIL PROTECTED]) - it seems that noone cares, but I'll repost a summary that Anders sent me below: --- Scenario 1: Mailservers: 2.6.10 (~24-40 hours uptime): Running ext3 on mailqueue: Unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: c018a095 *pde = Oops: 0002 [#1] SMP Modules linked in: nfs e1000 iptable_nat ipt_connlimit rtc CPU:2 EIP:0060:[]Not tainted EFLAGS: 00010286 (2.6.8.1) EIP is at journal_commit_transaction+0x535/0x10e5 eax: cac1e26c ebx: ecx: f7cec400 edx: f7cec400 esi: f65f3000 edi: cac1e26c ebp: f65f3000 esp: f65f3dc0 ds: 007b es: 007b ss: 0068 Process kjournald (pid: 174, threadinfo=f65f3000 task=c2308b70) Stack: f65f3e64 f7cec400 cda565fc 149a 0004 f65f3e48 c01132d8 0002 c202ad20 0001 f65f3e5c c202ad20 c202ad20 0002 0001 001e 01c1af60 f65f3e68 c0407dc0 Call Trace: [] scheduler_tick+0x468/0x470 [] find_busiest_group+0x105/0x310 [] del_timer_sync+0x7e/0xa0 [] kjournald+0xbd/0x230 [] autoremove_wake_function+0x0/0x40 [] autoremove_wake_function+0x0/0x40 [] ret_from_fork+0x6/0x14 [] commit_timeout+0x0/0x10 [] kjournald+0x0/0x230 [] kernel_thread_helper+0x5/0x18 Code: f0 ff 43 04 8b 03 83 e0 04 74 4c 8b 8c 24 b8 01 00 00 c6 81 <2>SoftDog: Initiating system reboot --- Scenario 2: Mailservers: Running XFS on mailqueue: Filesystem "sdb1": xfs_trans_delete_ail: attempting to delete a log item that is not in the AIL xfs_force_shutdown(sdb1,0x8) called from line 382 of file fs/xfs/xfs_trans_ail.c. Return address = 0xc0216a56 @Linux version 2.6.9 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-113)) #1 SMP Tue Oct 19 16:04:55 CEST 2004 === Resolution to the mailserver problem: 2.4.28 is perfectly stable on these machines. --- Scenario 3: Webservers: 2.6.10, 2.6.10-ac8 (~3-12 hours uptime): Unable to handle kernel paging request <2>SoftDog: Initiating system reboot. (No more...) :( === Resolution to the webserver problem: 2.4.28/2.4.29-rc2 are stable here --- Scenario 4: Storageservers: 2.6.8.1: Oopses after ~5-10 hours whith SMP on. - Cannot find the actual Oopses anymore and 2.6.8+ havent been tested as we cannot afford anymore downtime on these servers. === Resolution to the storage server problem: 2.6.8.1 UP is stable (but oopses regularly after memory allocation failures) Hardware on all servers: IBM x335 and x345. Mentioned errors seen on a total of 17 servers. - 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: Linux-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
I don't mean to walk on folks but I did make a patch that brings the ac27 version from aic7xxx-6.1.5 to aic7xxx-6.1.8. I've compiled it and inserted it and removed it without any of the hanging problems I encountered before. But the tests stopped there, no guarantees from me, I wish I could ;-) Please ignore this if you get something better. I included Mr. Gibbs changelog (for the changes from 6.1.5 to 6.1.8 his log is QUITE detailed.) Thanks to everyone! -- Jeffrey Hundstad Alan Cox wrote: > > What version of the aic7xxx driver is embedded in 2.4.2-ac27? This > > particular issue was fixed just after 6.1.5 was released. > > The last patch you sent to me + small other fixups for aicdb.h. I dont have > time to chase after peoples drivers. If you want a newer aic7xxx in -ac just > mail me a diff to update to it CHANGELOG-6.1.5-6.1.8.gz linux-2.4.2-ac27-aic7xxx-6.1.5-6.1.8.patch.gz
Re: Linux-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
aic7xxx_osm.h:#define AIC7XXX_DRIVER_VERSION "6.1.5" "Justin T. Gibbs" wrote: > >Hello, > > > >I'm using Linux-2.4.2-ac27 SMP compiled with gcc version 2.95.2 2220 > >(Debian GNU/Linux). > > What version of the aic7xxx driver is embedded in 2.4.2-ac27? This > particular issue was fixed just after 6.1.5 was released. > > -- > Justin - 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/
Linux-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
Hello, I'm using Linux-2.4.2-ac27 SMP compiled with gcc version 2.95.2 2220 (Debian GNU/Linux). After an "insmod aic7xxx" "cat /proc/bus/pci/devices" works just fine. After an "rmmod aic7xxx" "cat /proc/bus/pci/devices" fails to produce any output and never finishes. Top show the process in R state taking as much CPU as it can get. Killing the process doesn't do anything, rebooting is the only way to get rid of it. This problem does not happen with aic7xxx_old. Strace shows a "read" on the fd of /proc/bus/pci/devices that never finishes. My aic7xxx devices as reported by "lspci -vvv": 00:12.0 SCSI storage controller: Adaptec AIC-7881U (rev 01) Subsystem: Adaptec: Unknown device 7881 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lvm - lvm_map access beyond end of device
Andreas Dilger wrote: > Jeffrey Hundstad writes: > > After about 27 days of uptime one of our Linux machines that is being > > used as a Samba, Netatalk, and FTP server; the main data mount went into > > a read-only state. > [snip] > > We are mounting that 656GB disk as an EXT2 mount on /data. > > As an aside, other than this problem, how do you find ext2 on such a large > filesystem? So far this is the largest ext2 filesystem I've seen. Are > you looking into ext3 at all to avoid fsck on crash? Granted, in this > case you still needed to do the whole fsck but in other cases ext3 would > help. EXT2 is nice and snappy. This is our first crash... but the fsck was fun to watch ;) We might switch if there is a stable alternative. I've used EXT3 on my personal system and it worked fine, and it was really sweet to move from EXT2<->EXT3. Do you recommend it for a production system? Why isn't it in 2.2.18 OR 2.4.x? > > > ...during normal use we got events in our syslog (attached), also note > > the RAID controller showed no events. After a umount of the mounted > > filesystem, a reboot then a fsck the system worked fine. There > > were no bad reports from the fsck. Yes, I said no bad reports from > > fsck, it did take 3.5 hours though. What's causing this? > > > > Mar 8 01:15:47 files kernel: lvm - lvm_map access beyond end of device; > > *rsector: 2451636592 or size: 8 wrong for minor: 0 > > Mar 8 01:15:47 files kernel: Bad lvm_map in ll_rw_block > > Mar 8 01:15:47 files kernel: EXT2-fs error (device lvm(58,0)): > > ext2_readdir: bad entry in directory #43122713: rec_len is smaller than > > minimal - offset=0, inode=0, rec_len=0, name_len=0 > > Mar 8 01:15:47 files kernel: Remounting filesystem read-only > > Mar 8 01:15:48 files kernel: lvm - lvm_map access beyond end of device; > > *rsector: 2596938272 or size: 8 wrong for minor: 0 > > Mar 8 01:15:48 files kernel: Bad lvm_map in ll_rw_block > > Mar 8 01:15:48 files kernel: EXT2-fs error (device lvm(58,0)): > > ext2_readdir: bad entry in directory #43122714: rec_len is smaller than > > minimal - offset=0, inode=0, rec_len=0, name_len=0 > > Mar 8 01:15:48 files kernel: Remounting filesystem read-only > > Is this the only output in your syslog, a representative sample, a > small part of a huge number of messages? How often do you have this > problem, or is it the first time? > This was a `grep kernel` of the days syslog file. I did take a look and it was the only thing relevant. > > Can you verify that inodes 43122713 and 43122714 are actually valid > directories or at least valid inode numbers? dumpe2fs -h should be > enough to tell you the number of inodes in the filesystem. > # dumpe2fs -h /dev/vg0/lv0 Filesystem volume name: Last mounted on: Filesystem UUID: 1e473942-d8f1-4e48-905f-2f872f7e4424 Filesystem magic number: 0xEF53 Filesystem revision #:1 (dynamic) Filesystem features: filetype sparse_super Filesystem state: not clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 87375872 Block count: 174723072 Reserved block count: 0 Free blocks: 163429202 Free inodes: 86687944 First block: 0 Block size: 4096 Fragment size:4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16384 Inode blocks per group: 512 Last mount time: Thu Mar 8 12:28:00 2001 Last write time: Thu Mar 8 22:42:13 2001 Mount count: 1 Maximum mount count: 20 Last checked: Thu Mar 8 12:27:58 2001 Check interval: 15552000 (6 months) Next check after: Tue Sep 4 13:27:58 2001 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 > > According to my calculations for your 656 GB 4kB block filesystem: > > sector 2451636592 / 8 sectors/block = 306454574 > sector 2596938272 / 8 sectors/block = 324617284 > > 656 GB * 1024 MB/GB * 256 blocks/MB = 171966464 blocks > > So LVM is correct in refusing to map these blocks. The real question is > where do the block numbers come from? The "bad entry" messages are > simply a result of LVM not filling in the buffer for ext2, and it is > all zeros. > > The first point where we could have a bogus block number would be > in inode_getblk(), where we access inode->u.ext2_i.i_data[0] (the > block number here is not checked), but you say that e2fsck reported > all was well. > > The below patch for 2.2.18 v
lvm - lvm_map access beyond end of device
Hello, Vital info: Linux-2.2.18 LVM version 0.9 by Heinz Mauelshagen (13/11/2000) gcc version 2.95.2 GDT7563RN Firmware 2.27.04-R03F After about 27 days of uptime one of our Linux machines that is being used as a Samba, Netatalk, and FTP server; the main data mount went into a read-only state. The machine has a GDT7563RN ICP Vortex RAID card with 6-SCSI channels. Five channels are being used with nine 18GB disks on each channel. The RAID controller takes those 45 disks and makes three RAID-5 units with two hot-spares. We are using LVM to take those three RAID disks and striping those to one big block device. We are mounting that 656GB disk as an EXT2 mount on /data. During testing we banged the h*ll out of it with multiple bonnie tests and never found a problem. But during normal use we got events in our syslog (attached), also note the RAID controller showed no events. After a umount of the mounted filesystem, a reboot then a fsck the system worked fine. There were no bad reports from the fsck. Yes, I said no bad reports from fsck, it did take 3.5 hours though. What's causing this? Inline attachments syslog, dmesg-boot. syslog: Mar 8 01:15:47 files kernel: lvm - lvm_map access beyond end of device; *rsector: 2451636592 or size: 8 wrong for minor: 0 Mar 8 01:15:47 files kernel: Bad lvm_map in ll_rw_block Mar 8 01:15:47 files kernel: EXT2-fs error (device lvm(58,0)): ext2_readdir: bad entry in directory #43122713: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0 Mar 8 01:15:47 files kernel: Remounting filesystem read-only Mar 8 01:15:48 files kernel: lvm - lvm_map access beyond end of device; *rsector: 2596938272 or size: 8 wrong for minor: 0 Mar 8 01:15:48 files kernel: Bad lvm_map in ll_rw_block Mar 8 01:15:48 files kernel: EXT2-fs error (device lvm(58,0)): ext2_readdir: bad entry in directory #43122714: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0 Mar 8 01:15:48 files kernel: Remounting filesystem read-only dmesg-boot: 1189 0d 000 00 100 0 00000 0e 000 00 000 0 01191 0f 000 00 000 0 01199 10 0FF 0F 110 1 011A1 11 0FF 0F 110 1 011A9 12 000 00 100 0 00000 13 0FF 0F 110 1 011B1 14 000 00 100 0 00000 15 0FF 0F 110 1 011B9 16 000 00 100 0 00000 17 0FF 0F 110 1 011C1 IRQ to pin mappings: IRQ0 -> 2 IRQ1 -> 1 IRQ3 -> 3 IRQ4 -> 4 IRQ6 -> 6 IRQ7 -> 7 IRQ8 -> 8 IRQ12 -> 12 IRQ13 -> 13 IRQ14 -> 14 IRQ15 -> 15 IRQ16 -> 16 IRQ17 -> 17 IRQ19 -> 19 IRQ21 -> 21 IRQ23 -> 23 done. checking TSC synchronization across CPUs: passed. PCI: PCI BIOS revision 2.10 entry at 0xfdab0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI->APIC IRQ transform: (B0,I12,P0) -> 19 PCI->APIC IRQ transform: (B0,I12,P0) -> 19 PCI->APIC IRQ transform: (B0,I13,P0) -> 17 PCI->APIC IRQ transform: (B0,I14,P0) -> 21 PCI->APIC IRQ transform: (B0,I16,P0) -> 16 PCI->APIC IRQ transform: (B0,I16,P1) -> 21 PCI->APIC IRQ transform: (B0,I18,P3) -> 21 PCI->APIC IRQ transform: (B2,I7,P0) -> 23 Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP TCP: Hash tables configured (ehash 524288 bhash 65536) Starting kswapd v 1.5 Detected PS/2 Mouse Port. pty: 256 Unix98 ptys configured Real Time Clock Driver v1.09 RAM disk driver initialized: 16 RAM disks of 4096K size loop: registered device at major 7 PIIX4: IDE controller on PCI bus 00 dev 91 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x3060-0x3067, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x3068-0x306f, BIOS settings: hdc:pio, hdd:pio Floppy drive(s): fd0 is 1.44M FDC 0 is a National Semiconductor PC87306 LVM version 0.9 by Heinz Mauelshagen (13/11/2000) lvm -- Driver successfully initialized Configuring GDT-PCI HA at 0/13 IRQ 17 scsi0 : GDT7563RN scsi : 1 host. Vendor: ICP Model: Host Drive #00 Rev: Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 Vendor: ICP Model: Host Drive #15 Rev: Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdb at scsi0, channel 0, id 15, lun 0 Vendor: ICP Model: Host Drive #29 Rev: Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdc at scsi0, channel 0, id 29, lun 0 scsi : detected 3 SCSI disks total. SCSI device sda: hdwr sector= 512 bytes. Sectors= 501790275 [245014 MB] [245.0 GB] SCSI device sdb: hdwr sector= 512 bytes. Sectors= 465949260 [227514 MB] [227.5 GB] SCSI device sd
netatalk refuses to start with ethernet aliasing
Hello, I'm using Debian Potato with linux-2.2.18pre22. This version of Potato uses netatalk (1.4b2+asun2.1.3). Everything works just fine if I have the two interfaces: lo eth0 As soon as I alias eth0 and have the interfaces: lo eth0 eth0:0 eth0:1 eth0:2 netatalk refuses to start and I receive this in syslog: Nov 22 17:01:23 files atalkd[177]: restart (1.4b2+asun2.1.3) Nov 22 17:01:24 files atalkd[177]: zip_getnetinfo for eth0 Nov 22 17:01:25 files atalkd[177]: zip gnireply from 275.241 (eth0 12) Nov 22 17:01:26 files atalkd[177]: zip_packet configured eth0 from 275.241 Nov 22 17:01:26 files atalkd[177]: setifaddr: eth0:0: No such device Nov 22 17:01:26 files atalkd[177]: difaddr(65280.0): No such device Nov 22 17:01:26 files atalkd[177]: difaddr(0.0): No such device Nov 22 17:01:26 files atalkd[177]: difaddr(0.0): No such device Nov 22 17:01:26 files atalkd: difaddr(0.0): No such device Nov 22 17:01:26 files last message repeated 2 times Nov 22 17:01:27 files afpd[180]: main: atp_open: Cannot assign requested address My current work around is: 1. start the interfaces: lo eth0 2. start netatalk 3. create my eth0 aliases. This works fine... but is a little strange. Thanks for your help, Jeffrey Hundstad [EMAIL PROTECTED] Minnesota State University, Mankato http://www.mnsu.edu/jeffrey/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
