Re: [PATCH] ip_tables.h
On 4/7/07, Patrick Ale <[EMAIL PROTECTED]> wrote: And my "patch" is made obsolete :P Jan Engelhard from the netfilter list made patch set within the patch-o-matic tree. Cheers Jan :D Patrick - 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] ip_tables.h
On 4/7/07, Patrick Ale <[EMAIL PROTECTED]> wrote: Hi lads, Oh! And! I don't want to take credit for things I didn't write, which is this exactly. I merely got the ip_tables.h header from 2.6.20 and filtered out what I needed to get things work. So, the actual credit for the code in the patch goes to the person who put it in ip_tables.h under 2.6.20. So whoever you are, thanks :) - 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/
[PATCH] ip_tables.h
Hi lads,
I had some problems compiling the external netfilter modules due to
missing definitions.
I googled a lot, saw a lot of people having the same problems but no
real answer to how to fix it.
So.. I made a little patch which make things work for me, at least.
Modules that work after applying the patch are the geopip module,
connlimit module, and prolly more, but I didnt test them.
Please note, I am not a coder, not a maintainer and I am happy that I
didnt break anything so please don't consider this as a proposal to
include in the kernel or something, I am just in favor of sharing what
helped me getting things to work, if i can help others with it or if
it is interesting material for inclusion, even better :)
So, the patch is attached in this email and can also be found on
http://www.patrickale.eu/documents/archives/patches/ip_tables.h.diff
I hope this helps a people or two.
Patrick
--- include/linux/netfilter_ipv4/ip_tables.h.orig 2007-04-07 20:30:25.344365707 +0200
+++ include/linux/netfilter_ipv4/ip_tables.h2007-04-07 20:34:05.076887550 +0200
@@ -34,6 +34,12 @@
#define ipt_table xt_table
#define ipt_get_revision xt_get_revision
+#define ipt_register_match(mtch)\
+({ (mtch)->family = AF_INET; \
+xt_register_match(mtch); })
+#define ipt_unregister_match(mtch) xt_unregister_match(mtch)
+
+
/* Yes, Virginia, you have to zero the padding. */
struct ipt_ip {
/* Source and destination IP addr */
Re: sata_sil problems with recent kernels
On 3/5/07, Tejun Heo <[EMAIL PROTECTED]> wrote: Dale Blount wrote: This will probably included in the next -stable iteration. Thanks. -- tejun I can confirm that sata_sil is working great under 2.6.21-rc1. I have an onboard Silicon Image SATA RAID controller and a PCI Add-on card, also with silicon image chipset. 2x500GB Samsung 1x400GB Samsung I am getting maximum troughput and no errors of any kind. Patrick - 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: [IPW3945] Can't load microcode
On 3/5/07, Lee Revell <[EMAIL PROTECTED]> wrote: Hi all, Sorry for the confusion :) I saw an email from an Intel guy here on this list a couple of weeks ago if I recall correctly regarding the Interl drivers for this specific card, with a URL, thats why I assumed this was the place to look for. I didnt even know that 2.6.21-rc1/2 had in-tree drivers for this network card, which config option is that? Oh and like always, thanks for your help :) Patrick - 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: [IPW3945] Can't load microcode
On 3/4/07, Patrick Ale <[EMAIL PROTECTED]> wrote: Hi, I just downloaded the latest kernel drivers, daemon and microcode for my Intel Wireless card. everything built correctly, the microcode is placed in /lib/firmware and when running /etc/init.d/ipw3945d-start I get the following dmesg Extra info: When doing a /sbin/ipw3945d --kill && /sbin/ipw3945d I get: ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection ipw3945: uCode verification failed at addr 0x3800+0 (of 2396) ipw3945: Unable to load firmware: -5 ipw3945: MAC is in deep sleep! ipw3945: Unable to load firmware: -5 ipw3945: MAC is in deep sleep! ipw3945: Unable to load firmware: -5 ipw3945: MAC is in deep sleep! ipw3945: Unable to load firmware: -5 ipw3945: MAC is in deep sleep! ipw3945: Unable to load firmware: -5 ipw3945: MAC is in deep sleep! ipw3945: MAC is in deep sleep! ipw3945: MAC is in deep sleep! ipw3945: MAC is in deep sleep! ipw3945: Unable to initialize device after 5 attempts. ipw3945: MAC is in deep sleep! ipw3945: Unable to int nic ipw3945: MAC is in deep sleep! ipw3945: Unable to int nic ipw3945: MAC is in deep sleep! ipw3945: Unable to int nic ipw3945: MAC is in deep sleep! ipw3945: Unable to int nic ipw3945: MAC is in deep sleep! ipw3945: Unable to int nic ipw3945: MAC is in deep sleep! ipw3945: Unable to int nic - 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/
[IPW3945] Can't load microcode
Hi, I just downloaded the latest kernel drivers, daemon and microcode for my Intel Wireless card. everything built correctly, the microcode is placed in /lib/firmware and when running /etc/init.d/ipw3945d-start I get the following dmesg ieee80211_crypt: registered algorithm 'NULL' ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation <[EMAIL PROTECTED]> ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0d ipw3945: Copyright(c) 2003-2006 Intel Corporation ACPI: PCI Interrupt :05:00.0[A] -> GSI 18 (level, low) -> IRQ 22 PCI: Setting latency timer of device :05:00.0 to 64 ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection ipw3945: ipw3945.ucode load failed: Reason -2 ipw3945: Could not read microcode: -2 ipw3945: probe of :05:00.0 failed with error -2 What am I doing wrong? Patrick - 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: [PROBMEL] MD doesn't like /dev/disk/by-id
On 2/26/07, Neil Brown <[EMAIL PROTECTED]> wrote: ARRAY /dev/md1 UUID=x:x:Xx:x and it should find the right devices and assemble them without problems. That's my point, this is the *only* way working at the moment when using mdadm --assemble , since /dev/disk/by-id* tells me no suiteable drives, /dev/sd? DOES work but isnt reliable since /dev/sdl is not always /dev/sdl but can be /dev/sdc the next reboot :D The only supported way to assemble arrays when md is a module is to use mdadm. Mdadm has several ways to identify an array. Check the man page. I know, and i use mdadm. I used to use /dev/sd? since I did a simple migration from raidtools to mdadm and this was the easiest way, then I started to use libata which mangled my drive order every reboot, so I got adviced to use /dev/disk/by-id/* , and now I am using UUID=some 128 bits hash here Suggestions for specific improvements to the md and mdadm documentation are always welcome. Read mdadm.8 again and then tell me what you wanted it to tell you that wasn't clear. Well, what I am kinda trying to say is: function that used to work prior to 2.6.20 doesn't seem to be working anymore :D mdadm -assemble doesn't work with /dev/disk/by-id/* is used. And /dev/sd? is not useable due to the drive order not being the same after every reboot, but this is more a libata/udev problem I guess. I am in the train now, I will do the mdadm -v thingy as soon as I am at a somewhat more stable connection than 2Mbit HDPSA Patrick - 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/
[PROBMEL] MD doesn't like /dev/disk/by-id
Hi, I posted this a while ago aswell :) MD can't start anymore when /etc/mdadm.conf uses /dev/disk/by-id/* , it bluntly tells you there are no suiteable drives. Since libata tends to mangle my drive order by every reboot since I use 3 controllers and the drivers dont generate uevents always in the same sequence the only thing left to use are UUIDs. Now, this isnt a problem but is this the *only* way the mdadm devices will startable now and is this the only way the MD module will support? And if yes, maybe this should be communicated somewhere, cause something tells me I am not the only one who had this problem or will have :) Patrick - 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: [QUESTION] Sata RAID
On 2/24/07, Patrick Ale <[EMAIL PROTECTED]> wrote: On 2/24/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote: One more question regarding this, I am aware its not *really* kernel related but answering this question now will save yourself a lot of bogus emails from me about MD oopses later and all, and I want to setup my disks right once and for all and never witness what I witnessed last weeks with my ATA disks. Would you use MD at all, taking in account the disks come from the same batch and all? I hear these things about MD/RAID being pointless when you use disks from the same brand/type/batch since they most likely will break shortly after eachother. Oh, and one more thing \|/ \|/ "@'/ ,. \`@" /_| \__/ |_\ \__U_/ <--- whoeveer programmed that into the sparc-linux oops is GOD, you're my true hero, lol. Patrick - 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: [QUESTION] Sata RAID
On 2/24/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote: But using 'fakeraid' (i.e. BIOS RAID) together with dmraid is generally discouraged in favour of using the more stable and well supported Linux Software RAID functionality. Michael-Luke I think I actually used dmraid, and the problem I had in those days was that it was just a layer over your legacy IDE drivers. With 2.4 you had "real" drivers whom created block devices if I recall correctly which you could really treat as disks. If dmraid still works as it did in the days I used it it's just a layer, like LVM, and the kernel itself doesnt care at all for the disks being in a RAID set or not and will access the disks independently, this I really found a reason to not use dmraid and stick with MD devices. And by the reactions from you guys I guess those reasons still exist :) So MD it is, Thanks! Patrick - 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/
[QUESTION] Sata RAID
Hi, Quick question, Since I am going to open my server today to do some pata tests (for the weird detection problems people are giving me fantastic help with, no sarcasm, I really mean it) I thought: why not add two 320GB SATA disks on the SATA controller that the mainboard has. I am wondering: should I use the onboard RAID function? Is this supported by Linux? I remember back in "the old days (TM)" there were seperate (spelling) drivers for ataraid, how does the current 2.6 branch cope with the RAID functions of modern motherboards? I am aware that it is NOT hardware raid, the raid is done in the driver, which is why you need this fancy boot disk before installing Windows on your RAID set. Or would you suggest me to stick with MD devices? Cheers, Patrick Ale [EMAIL PROTECTED] "kun kasvan isoksi, halun olla poro" - 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/
[UMTS/HSDPA] Kernel module
Hi All! For my work I am using a Huawei E620 HSDPA/UMTS card, and I would like to use it under Linux :) Before this I had a card with only UMTS/GPRS functions and as soon as I inserted the card some /dev/ttyUSB nodes were created, with this card this doesnt happen, eventho the different fora say it should. On one of the fora I see that an external module exists for this card, but when I try to compile it it tells me TTY_DONT_FLIP is not defined. This sounds like something that should be (or used to be) defined by tty_driver.h or tty_flip.h. Does anyone have an idea of how to use this card or compile these drivers needing the TTY_DONT_FLIP? Thanks, Patrick - 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: [SKY2] Does anyone have this driver working?
On 2/22/07, Paul Rolland <[EMAIL PROTECTED]> wrote: Hello, hey all, using 2.6.21-rc1 now, all seems to work great, thanks! patrick - 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: libsata doesn't like bus without master
On 2/22/07, Paul Rolland <[EMAIL PROTECTED]> wrote: Hello, I dont think there is one or that this reply of yours could cause it :P Just to add my $0.02 on this point : this could also be one of the problem I'm facing on my machine right now, but the point is that Windows supports it perfectly. At least that proves it can work, and it does work. If I read the posts correctly it was allready established that the drivers in Linux should support this but yes, I do agree with you, whatever a BIOS supports should be supported by the kernel as well in my opinion. And, at least the BIOSes and drives I used, support single slave operations, how stupid this might be :) Anyways, today is my first day at work again after a fever, so I will be messing with stuff and hardware again, and will try to do some more tests/breakage hoorah. Patrick - 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/
[SKY2] Does anyone have this driver working?
Hi, And now, for something completely different, no libata ;-) I was wondering if any of you ever got the sky2 driver working (gigabit network card found in most Siemens E laptops). Which kernel I am trying, 2.6.17-gentoo (the kernel on the install CD), 2.6.20, the latest gits, nothing works. It either tells me "Link not ready" when bringing the interface up or it just gives massive time outs. Then, after literaly 6 reboots, it might get a DHCPACK, work, till the next reboot, then same story all over again. Any clue towards module settings or patches are welcome, At the moment I am compiling Jeff's netdev upstream-linus. Patrick - 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: libsata doesn't like bus without master
On 2/21/07, Patrick Ale <[EMAIL PROTECTED]> wrote: On 2/21/07, Vincent Legoll <[EMAIL PROTECTED]> wrote: In the latter case it might explain why you see one master connected to one bus and a slave to the other. If you use legacy SATA mode you should just see drive 0 and drive 1. Oh and! In case you use native SATA your harddisk will be driven by the sata driver, and your CD-ROM driver by the pata driver, which in case of piix is all the same driver so no worries there, but I thought this would be nice to know information never the less :) Patrick - 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: libsata doesn't like bus without master
On 2/21/07, Vincent Legoll <[EMAIL PROTECTED]> wrote: Argh I think I screwed the mail threading, I was refering to: http://ussg.iu.edu/hypermail/linux/kernel/0702.1/1060.html From: Patrick Ale Date: Sun Feb 11 2007 - 05:28:21 EST Sorry Yea, I know.. I mail too much.. too much time at hands and all ;-) But serious, The second "abnormal" error "ATA: abnormal status 0x8 on port 0xF88597DF", I got feedback from, by Tejun. He confirmed that, as I thought, this was a cosmectic error messages for "No devices found". The first one got some debate as if it was legal to have a slave without a master and all and the last thing I saw written on this email that we (that is, the linux developers and the maintainers, I dont code anything other than 'Hello world' and even that might segfault) should support it and if we dont yet, fix it. Question for you tho, since I have two laptops with the same chipset and more ore less same configuration (Siemens LifeBook E series with the same DVD writer and an HP laptop), do you use native SATA mode? or Legacy/Compatible mode? In the latter case it might explain why you see one master connected to one bus and a slave to the other. If you use legacy SATA mode you should just see drive 0 and drive 1. At least, that's how it works here :) Patrick - 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: [PROBLEM] compiling latest linus-upstream
On 2/18/07, Patrick Ale <[EMAIL PROTECTED]> wrote: Hi all, I just tried to compile Torvald's upstream-linus and ran into a compile error. Disregard, I ran make oldconfig again, didnt get prompted for any configuration options, and now it does compile. Patrick - 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/
[PROBLEM] compiling latest linus-upstream
Hi all, I just tried to compile Torvald's upstream-linus and ran into a compile error. CC arch/i386/kernel/time.o In file included from include/asm-i386/mach-default/do_timer.h:5, from arch/i386/kernel/time.c:75: include/asm/i8253.h: In function `pit_interrupt_hook': include/asm/i8253.h:18: error: dereferencing pointer to incomplete type make[1]: *** [arch/i386/kernel/time.o] Error 1 make: *** [arch/i386/kernel] Error 2 The pull is done 5 minutes ago. I attached my .config file, patrick # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20 # Fri Feb 16 19:58:22 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_LSF=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="deadline" # # Processor type and features # CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_X86_MCE_P4THERMAL is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=y CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set # CONFIG_NOHIGHMEM is not set # CONFIG_HIGHMEM4G is not set CONFIG_HIGHMEM64G=y CONFIG_PAGE_OFFSET=0xC000 CONFIG_HIGHMEM=y CONFIG_X86_PAE=y CONFIG_NEED_NODE_MEMMAP_SIZE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_
[QUESTION]
Allrighy, Since somebody up there hates me and passed me a cool fever with a body temperature of 39C I'll stay in bed, of course. But I wouldnt be me if I would be stopped by some inferior fever this weekend. So I am going to install my HP Pavilion dv8373 laptop with Linux. Two SATA disks connected to a ICH7, Nvidia 256MB video card, mmc card reader, bluetooth, firewire and a remote control. Anything you guys and girls know of what I can face during installation? Patrick - 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: libsata tests started
On 2/15/07, Ioan Ionita <[EMAIL PROTECTED]> wrote: All clear now? Yes sir, sorry. - 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: libsata tests started
On 2/15/07, Tejun Heo <[EMAIL PROTECTED]> wrote: Yeah and about the libsata/libata thingy, it is libata of course :) libsata I will test later on, so be prepared allready for more ranting for me. I even bought a cool sata controller with sata disk so I can mess around :D Patrick - 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: libsata tests started
On 2/15/07, Tejun Heo <[EMAIL PROTECTED]> wrote: I appreciate the testing. One interesting but tedious test would be suspend tests (both to disk and ram). Most libata drivers using new EH should be ready for them. Oh, well, there's should and there's reality. I will do these tests when I am at home, no problem :) - 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: [LIBATA] drives not detected
On 2/15/07, Patrick Ale <[EMAIL PROTECTED]> wrote: Good morning all, Now, when I boot up, I miss two drives, exactly the two connected to this promise card. I have another onboard Promise controller which works just fine, so the driver gets loaded properly, and since i see all my other disks but these two I think we can rule out a misconfiguration of the kernel config this time ;-) It would be nice if I'd also mention the kernel I use eh. It's linux-2.6-git8 Patrick - 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/
[LIBATA] drives not detected
Good morning all, Yesterday I replaced a Sil680 PCI add-on card for a Promise 2027x PCI add-on card. Now, when I boot up, I miss two drives, exactly the two connected to this promise card. I have another onboard Promise controller which works just fine, so the driver gets loaded properly, and since i see all my other disks but these two I think we can rule out a misconfiguration of the kernel config this time ;-) This is a snippet from my dmesg pata_pdc2027x :00:0b.0: version 0.74-ac5 ACPI: PCI Interrupt :00:0b.0[A] -> GSI 19 (level, low) -> IRQ 20 pata_pdc2027x :00:0b.0: PLL input clock 16799 kHz ata7: PATA max UDMA/133 cmd 0xf98a17c0 ctl 0xf98a1fda bmdma 0xf98a1000 irq 20 ata8: PATA max UDMA/133 cmd 0xf98a15c0 ctl 0xf98a1dda bmdma 0xf98a1008 irq 20 scsi7 : pata_pdc2027x scsi8 : pata_pdc2027x ATA: abnormal status 0x8 on port 0xf98a15df As you can see, scsi8 gives an abnormal status, which as we got pointed out this week is just a cosmetic error for "No drive attached/detected" and it's very right in that finding. But what about scsi7? no warning/error about no disks being attached nor a disk detection. To state the obvious: I see the disks being detected by the Promise BIOS when I boot the system,Primaiy master and Primaiy slave. Here is the lspci -vvv regarding the controller 00:0b.0 Mass storage controller: Promise Technology, Inc. 20269 (rev 02) (prog-if 85) Subsystem: Promise Technology, Inc. Ultra133TX2 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xfs internal error on a new filesystem
On 2/14/07, Ramy M. Hassan <[EMAIL PROTECTED]> wrote: Hello, We got the following xfs internal error on one of our production servers: Hi, I want firstly to make a disclaimer that I am not an XFS or kernel guru, what I am writing now is purely my experience, since I use XFS on all my machines, on different disks and all. I encountered the problem you have now, twice over the past three years. Once it was caused by a faulty disk where the 8MB cache on the disk was faulty, causing corruption, and one time it was cause of, what seems to be, a CPU that couldnt handle XFS. This sounds illogical, and to me too, honestly, but the explanation I got was that XFS writes are quite CPU intensive, especialy when you write with 500MB/s and we tried to do this on a PII-400Mhz. I tried reiserfs aswell, and I honestly cant give you one reason to switch back to it. I love XFS, always did, its fast and reliable. Problems that I had were never related to XFS but to hardware that had to deal with XFS in a way (CPU/disk). And, xfs_repair DID repair my filesystems, the data was on the disks, and valid, XFS just shut down my filesystem cause it found my journal not reliable/corrupted. Again, please be aware that I am just a regular user who likes to play around with linux and the kernel, I am no expert in the field of XFS or its relations. I hope this helps you a bit. Patrick - 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: [PROBLEM] Can't start MD devices by using /dev/disk/by-id
> Just out of curiosity, why did you do this in such a manual way instead of just using the UUID? I would think every time you replace a failed drive you would have to go edit the files all over again. Oh, there is a very simple reason for that. These md arrays exist for a year of three allready, from the time I used raidtool instead of mdadm. So when I switched to to mdadm, I just got the /etc/raidtab file and migrated it to /etc/mdadm.conf, since /etc/raidtab worked with blockdevices and not UIDs (correct me if I am wrong and overlooked this featute), the mdadm.conf ended up with these devices too. Next to that, there is a, for me at least, practicle reason. I keep adding harddisks, and when I use the block devices rather than UIDS, and I get problems like yesterday, I have the blockdevice or serial number of the disk, which makes it easier to look in my case where the potential problem might be. If I work with UIDs and something goes wrong when doing an mdadm --assemble, then I'll first have to look up which disks belong to which UID, which costs time. OR! which is also very possible, maybe there is a way easier way to pinpoint which drives belong to which array before starting the array, which I don't know about yet. So please, if you have suggestions, let me know :) Take care! Patrick - 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/
[PROBLEM] Can't start MD devices by using /dev/disk/by-id
Hi chaps, I just came home, rebooted my box to git8 and *gasp* a problem :) I can't start my MD devices anymore by defining /dev/disk/by-id/* devices in /etc/mdadm.conf. When I do a: mdadm --assemble /dev/md/1 it tells me "No devices found for /dev/md/1" When I edit the file /etc/mdadm.conf and change the /dev/disk/by-id/* to whatever the symbolic links points to in the /dev directory, it does work. An example: -- mdadm.conf ARRAY /dev/md/1 devices=/dev/disk/by-id/scsi-SATA_WDC_WD1200JB-00WD-WMAEL2258179-part1,/dev/disk/by-id/scsi-SATA_WDC_WD1200JB-00WD-WMACM1329740-part1 #ARRAY /dev/md/1 devices=/dev/sdb1,/dev/sdf1 ARRAY /dev/md/2 devices=/dev/disk/by-id/scsi-SATA_Maxtor_6L250R0_L609D78H-part1 ARRAY /dev/md/3 devices=/dev/disk/by-id/scsi-SATA_WDCD1600JB-00WD-WMAEK2977810-part1,/dev/disk/by-id/scsi-SATA_Maxtor_6Y160P0_Y48BCM3E-part1 -- end mdadm.conf -- localhost by-id # pwd /dev/disk/by-id localhost by-id # mdadm --assemble /dev/md/1 mdadm: no devices found for /dev/md/1 Let's change the config file now -- mdadm.conf -- #ARRAY /dev/md/1 devices=/dev/disk/by-id/scsi-SATA_WDC_WD1200JB-00WD-WMAEL2258179-part1,/dev/disk/by-id/scsi-SATA_WDC_WD1200JB-00WD-WMACM1329740-part1 ARRAY /dev/md/1 devices=/dev/sdb1,/dev/sdf1 ARRAY /dev/md/2 devices=/dev/disk/by-id/scsi-SATA_Maxtor_6L250R0_L609D78H-part1 ARRAY /dev/md/3 devices=/dev/disk/by-id/scsi-SATA_WDCD1600JB-00WD-WMAEK2977810-part1,/dev/disk/by-id/scsi-SATA_Maxtor_6Y160P0_Y48BCM3E-part1 And localhost by-id # mdadm --assemble /dev/md/1 mdadm: /dev/md/1 has been started with 2 drives. Now, granted, it's 22:49 and i had a sucky day at work but... this doesnt make any sense to me. So, I tried to use the vanilla 2.6.20 kernel, same problem. Here is a listing of symbolic links in /dev/disk/by-id , as you can see the initial mdadm.conf (which worked prior to 2.6.20) should work, since the links to the actual device nodes seem to be correct and taking in account the MD devices do start when using the /dev/ nodes. lrwxrwxrwx 1 root root 9 Feb 12 05:40 scsi-SATA_Maxtor_6L250R0_L609D78H -> ../../sdc lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_Maxtor_6L250R0_L609D78H-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 9 Feb 12 05:40 scsi-SATA_Maxtor_6Y160P0_Y48BCM3E -> ../../sde lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_Maxtor_6Y160P0_Y48BCM3E-part1 -> ../../sde1 lrwxrwxrwx 1 root root 9 Feb 12 05:40 scsi-SATA_WDC_WD1200JB-00WD-WMACM1329740 -> ../../sdf lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD1200JB-00WD-WMACM1329740-part1 -> ../../sdf1 lrwxrwxrwx 1 root root 9 Feb 12 05:40 scsi-SATA_WDC_WD1200JB-00WD-WMAEL2258179 -> ../../sdb lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD1200JB-00WD-WMAEL2258179-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 9 Feb 12 05:40 scsi-SATA_WDC_WD1600JB-00WD-WMAEK2977810 -> ../../sdd lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD1600JB-00WD-WMAEK2977810-part1 -> ../../sdd1 lrwxrwxrwx 1 root root 9 Feb 12 05:40 scsi-SATA_WDC_WD2000JB-00_WD-WCAL81971867 -> ../../sda lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD2000JB-00_WD-WCAL81971867-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD2000JB-00_WD-WCAL81971867-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD2000JB-00_WD-WCAL81971867-part3 -> ../../sda3 lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD2000JB-00_WD-WCAL81971867-part4 -> ../../sda4 lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD2000JB-00_WD-WCAL81971867-part5 -> ../../sda5 lrwxrwxrwx 1 root root 10 Feb 12 05:40 scsi-SATA_WDC_WD2000JB-00_WD-WCAL81971867-part6 -> ../../sda6 lrwxrwxrwx 1 root root 9 Feb 12 05:40 usb-USB2.0_CardReader_CF_RW_586148026074 -> ../../sdg Cheers, Patrick - 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: [LIBATA] Libata under Qemu
On 2/13/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: /That/ sounds like a qemu bug. Allright, I will make sure tonight by testing it on a native PIIX mainboard without anything connected to the second PATA controller :) I thought for a second it was a similar "abnorma statel" error I got earlier this week with pata_via when no drive was attached (no qemu, real hardware) I'll keep you posted. Patrick - 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: [LIBATA] Libata under Qemu
On 2/13/07, Patrick Ale <[EMAIL PROTECTED]> wrote: Hi, Little errata, I only pulled Jeff's GIT at 15:00GMT , Linus' GIT was from two days ago. I just pulled linux-2.6-git8, same behaviour tho, it complains when nothing is attached to the second channel. Patrick - 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: libsata tests started
So, my AMD Athlon XP2400+ with pata_pdc2027x, pata_sil680 and pata_via survived four days of bonnie++, emerge -e world, dd if=//dev/random of=/tmp/whatever, and most of all, four days of me :) SO I guess it's safe to assume I didn't find any weird things by using 2.6.20 and the new libata drivers. Now, since functionality by design is boring and my employer doesn't torture me enough,, I' pulled the libsata-dev git and linux-2.6 git and will see how that goes. Tests on my Siemens laptop are still in progress, since i have to reboot to windows every day (cooperate rules at work, network authentication, yadayada). I didnt have time yet to install Linux on my HP Pavilion dv8373 and on my Dual P2 400Mhz with Intel 440BX motherboard, but I hope to do this soon. Have a joyfull day and i hope you have better weather than we have here in Amsterdam. Patrick Ale Not even the best coder can -Dsense -Dsane me - 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: [QUESTION] Which dependency am I missing?
On 2/12/07, Patrick Ale <[EMAIL PROTECTED]> wrote: Hi folks, Disregard, I found the problem. CONFIG_NEW_LED=Y , so I have to do a make and boot from the produced image. Which brings me to another question. If a dependent driver is selected as module (for reasons you dont want to reboot and all), is it possible to have the dependencies built as module aswell rather than being built into the kernel? for CONFIG_NEW_LED I cant choose for built-in or module, it's built-in, and that's all there is possible. Patrick - 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/
[QUESTION] Which dependency am I missing?
Hi folks, I am looking for a half day now and I can't find the dependency for NEW_LED I am missing. Can anyone point me to what I am missing? 80211: Unknown symbol led_trigger_unregister 80211: Unknown symbol led_trigger_register 80211: Unknown symbol led_trigger_event 80211: Unknown symbol led_trigger_unregister 80211: Unknown symbol led_trigger_register 80211: Unknown symbol led_trigger_event led_class: Unknown symbol leds_list_lock led_class: Unknown symbol led_trigger_store led_class: Unknown symbol leds_list led_class: Unknown symbol led_trigger_set led_class: Unknown symbol led_trigger_show led_class: Unknown symbol led_trigger_set_default ledtrig_heartbeat: Unknown symbol led_trigger_unregister ledtrig_heartbeat: Unknown symbol led_trigger_register Patrick config-2.6.20-d80211-test Description: Binary data
Re: libsata doesn't like bus without master
On 2/11/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: On Sun, 11 Feb 2007, Robert Hancock wrote: > Then in that case you should set the remaining drive as master. That's > just the way PATA is. A lot of BIOSes won't even detect a drive that's > set as slave with no master present. For some stupid reason, it appears that the norm around here (Brazil) is that "no brand" boxes get assembled with ATAPI devices in slave mode. Usually they attach it to the second channel using an 40-wire cable, even if there is nothing using the first channel. Yes, this is actually one of the reasons i mentioned sometimes having only a slave drive can be a "legal" way to connect drives. I've lived in Curitiba and Rio for a while (familiar cities to you I guess) and sometimes we just had no choice to yank the master drive out of its bay and keep running with what we had, cause money wasnt exactly growing in trees where I used to work. Next to that, we had the so called "paraguay" quality assembled hardware, which basicly means someone, somewhere put some hardware together and if it didnt work, you had a problem since its all you could get. Now, I agree with Robert, people should assemble and maintain their hardware as much as possible, following the specs. But sometimes it just isnt possible to do that, for whatever the reason might be. And I honestly havent found any old or new mainboard that doesnt allow you to have only a slave drive. I did see the opposite tho. A master drive that just refused to get detected cause the jumper wasnt set to "master only" (hello Western Digital). I don't know, the error i saw is nothing critical, I am just wondering how valid the "abnormal" notation is, if you go by the specs of ATA, yes, it is. If you go by daily practice, then in my honest opinion, it isnt. Then again, there are way more important things to deal with right now than cosmetics :) Patrick - 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: libsata doesn't like bus without master
On 2/11/07, Robert Hancock <[EMAIL PROTECTED]> wrote: Patrick Ale wrote: > On 2/11/07, Robert Hancock <[EMAIL PROTECTED]> wrote: >> Patrick Ale wrote: Then in that case you should set the remaining drive as master. That's just the way PATA is. A lot of BIOSes won't even detect a drive that's set as slave with no master present. Yea, I guess you're right. For me it isnt a problem, This error message will disappear for me anyway, since I am going to re-add the drive now, like I said yesterday, I am re-adding stuff one by one, to isolate problems. I can just imagine that switching a jumper might not be as easy for everybody, especialy when they bought special front-loading harddisk bays for their disks and all, for the very reason of not having to open the case. Yeah, that's a better point. It's not really complaining, but we could probably have a better way of suppressing that message. I think it's largely there so that we can debug issues with drives not being detected when they should. It's not like it is causing any problems, nothing hangs or slows down at boot time, its just something I came across when checking my dmesg and wanted to inform the list so I could see if this was normal behaviour or not :) Patrick - 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: libsata doesn't like bus without master
On 2/11/07, Robert Hancock <[EMAIL PROTECTED]> wrote: Patrick Ale wrote: > Something unrelated to the tests I am doing. > > I found out that the libsata driver doesn't really cope or likes the > idea that you might have a controller without a master drive > configured. > > In this case on ATA2 I have a CDROM drive, connected as slave. > ATA: abnormal status 0x7F on port 0x177 > ATA: abnormal status 0x7F on port 0x177 > ata2.01: ATAPI, max UDMA/66 > ata2.01: configured for UDMA/66 Having a single drive on the channel configured as slave is not really a legal configuration. (I believe the ATA standards say that it's something that a host controller/driver/OS is allowed to support, but it is not required to.) A single drive should always be set to master (and connected to the end of the cable and not the middle, by the way). It is very legal when one of your harddisks blows out and you take it out temporarely and have no money for a replacement IMO. But then again, this is probably an abnormality. But still, it even complains when no drive is attached to a controller at all. Since when you buy an add-on PCI card you get 2 connectors even when you want to add one harddisk how does one deal with that? - 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/
libsata doesn't like bus without master
Hi, Something unrelated to the tests I am doing. I found out that the libsata driver doesn't really cope or likes the idea that you might have a controller without a master drive configured. In this case on ATA2 I have a CDROM drive, connected as slave. ATA: abnormal status 0x7F on port 0x177 ATA: abnormal status 0x7F on port 0x177 ata2.01: ATAPI, max UDMA/66 ata2.01: configured for UDMA/66 And in another case, I have ATA5 with no drives connected at all: pata_pdc2027x :00:0f.0: PLL input clock 33508 kHz ata5: PATA max UDMA/133 cmd 0xF88597C0 ctl 0xF8859FDA bmdma 0xF8859000 irq 19 ata6: PATA max UDMA/133 cmd 0xF88595C0 ctl 0xF8859DDA bmdma 0xF8859008 irq 19 scsi4 : pata_pdc2027x ATA: abnormal status 0x8 on port 0xF88597DF Maybe this is purely a cosmetic error where the error code can be translated to something like "no drive attached" or maybe the drivers assume you always configure a master drive on a controller, which doesnt always have to be the case, especialy not with motherboards these days where you get 2 ATA ports + 2 exta raid channels. Patrick - 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: libsata tests started
And again, for something completely different. I am hammering my second machine now, a cool Siemens/Fujitsu laptop (named elisabeth) with ICH7 ATA chipset and controller. Currently the ATA controller is in "SATA" mode (ICH7 chipsets allow you to run in native SATA mode or compatible mode, for the HP users, compatible == legacy mode). And for the interested, an lspci -vvv is attached of what goodies are onboard and what exactly we're testing against. Patrick 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) Subsystem: Fujitsu Limited. Unknown device 1378 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1 Link: Latency L0s <1us, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x1 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+ Slot: Number 2, PowerLimit 6.50 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- Slot: AttnInd Unknown, PwrInd Unknown, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Address: fee0300c Data: 41c9 Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [100] Virtual Channel Capabilities: [180] Unknown (5) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 2 Link: Latency L0s <1us, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x0 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+ Slot: Number 3, PowerLimit 6.50 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- Slot: AttnInd Unknown, PwrInd Unknown, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Address: fee0300c Data: 41d1 Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [100] Virtual Channel Capabilities: [180] Unknown (5) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 3 Link: Latency L0s <256ns, L1 <4us Link: ASPM L1 Enabled RCB 64 bytes CommClk+
Re: libsata tests started
On 2/10/07, Alan <[EMAIL PROTECTED]> wrote: Right umm "Your honor the gentleman is human, this is not acceptable" ? Human and a looney who wishes Monty Python's Flying Circus still existed so he could be a main character and having a great excuse to act weird. Beating the crap out of it using it for real work is one excellent form of testing. We aren't yet at the point of only worrying about benchmark tuning and corner cases. Exactly what I am doing :) I know bonnie++ is mostly used for benchmarking, but it also is a great tool to hammer down your hard-disks. I also break RAID1 arrays volunteerly (spelling) and resync them to do some stress tests on the disks, but I dont recommend others to do these kind of tests, unless you dont worry about your data, or are a fruitcake, like me. Patrick - 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: libsata tests started
On 2/10/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: Hi, What are the libsata tests and where are they, please? No where, I just compile the drivers, see if my system boots up and then I run some I/O intensive stuff, like bonnie++, emerge -e world at the same time. So you are testing libata and ext4dev at the same time... Not really, i dont focus on ext4dev, it just happens to be a partition that's empty and has 40GB of space left for disk writes. I mostly use XFS on my system. libsata == libata ? I don't think there is a seperate libata, it's all put under libsata if I understand the working correctly (Alan, don't sue me if I am wrong). Maybe it *IS* a nice idea to outline some standard tests that developers want to have carried out or some specific tests to trace bugs or test if a patch/fix does its work.. But that's not up to me, I am not a coder, I can do some very basic stuff in C, that's where programming ends for me, unless it's shell scripting. Patrick - 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/
libsata tests started
Hi, And now for something completely different. I started the libsata tests on one of the four machines I'll be doing these tests on. At the moment I'm testing on 'lilith', which is my multi-harddisk server and playground. At the moment I am hammering /dev/sda5, which is an ext4dev partition with bonnie++. sda is attached to my onboard ATA controller, driven by pata_via. At the same moment I am doing a full resync of my MD RAID1 device with two stripes. Both stripes are on seperate 120GB disks, where one disk is attached to a PCI controller, driven by pata_sil680 and one disk attached to an onboard Promise ATA controller, driven by pata_pdc2027x. I confirmed that all devices are driven by the new libsata drivers, it can't be very much differentr since I disabled the entire "old" IDE stack. :) So, let's see how things go, so far so good. For those who are interested, I attached the output of an lspci -vvv. The file name has "stage1" included since I'll be adding my PCI cards one by one to isolate problems to a single bus or card. I hope my test input helps a bit. Patrick 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge Subsystem: Giga-byte Technology GA-7VAX Mainboard Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:08.0 Mass storage controller: Silicon Image, Inc. SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02) Subsystem: Silicon Image, Inc. SiI 3112 SATALink Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 01:00.1 Display controller: ATI Technologies Inc RV350 AP [Radeon 9600] (Secondary) Subsystem: ATI Technologies Inc Unknown device 4151 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR-
Re: hdparm for lib_pata
Do you know if these drives were advertising less capability than they were spec-ed at? Do you recall if the IDE driver without kernel arguments printed its rationale for reverting to the slower setting? I can only speak for myself of course. On boot time the libsata driver detected my harddisks were capable of UDMA100, and used it. Then, after 2 hours, and resyncing RAID1 MD 1 devices, I started seeing things like: "Drive not ready" "DMA timeout on ..." After this, I saw a bus reset, the master disk (the one with problems) reverted to UDMA/44 and the slave (no problems appearantly staid (stayed?) at UDMA100. Then, after literaly some minutes, same messages, "Drive not ready" , "DMA timeout". And it went to an even lower UDMA mode, till the point it was out of UDMA modes, switched to PIO, and when it dropped to the lowest PIO mode, it just said how it couldnt go any lower I ask because I'd like to know if this sort of thing can ever happen with libata. If so, then that is yet another reason to have the ability to override DMA settings from user level in libata. Please note: I DID have problems, major ones, So yes, libsata does fall back to slower transfer modes, but as far of my experience concerned, not without a reason which should be addressed. Patrick - 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: hdparm for lib_pata
\ Userspace PIO mode changes are NOT a good idea, and I doubt that libata would want to support that feature. The "-d" flag (enable/disable DMA) is currently not implemented by libata, though there may be a /sys/.. attribute for it (?). Okay but... the driver itself does implement the calls, maybe in another way but it does switch from DMA to PIO. At boot time it uses UDMA100 and after some transfer speed downgrades even tells me how there is no lower mode available (which means its running in PIO mode 1 I guess). I agree that its not a good idea, and in normal cases, you wont even need it cause your hardware works properly. I had a closer look at my old kernel logs, and different from the old ata drivers, the new libsata drivers probe every disk for its UDMA capabilities and sets them per drive, also on a bus reset, rather than resetting the entire bus and using the same transfer setting for all drives on that bus (which is what i saw happening with my promise IDE card and the old IDE drivers. So, with the new drivers, one failing disk doesnt drag the other disk with him into PIO mode, at least, this is how I see things on my screen and how I experience it. The disk that does fall back to PIO mode probably does have a serious problem or, in my case, the entire southbridge is overheated causing lots of PCI problems (thanks Robert, for the point out, I changed the powersuply and the southbridge fan and all works great now). So, yeah, in general I like the idea of being in control of my machine, how dangerous that might be, but in the case of libsata and my experience with the new pata drivers so far, the driver knows what's best for me and acts like it and building some overriding controls for userspace just will break things, if not totaly destroy it. Actually all problems I had so far with libsata were pointable to my stupidity (hello CONFIG_DEV_SD) or hardware that was totaly failing. So, I give two thumbs up to the new libsata/pata drivers, I really like the way they work and I truely see advantages using them over the old IDE drivers, not in the last place cause it is much easier to see disk/bus problems now since I find the ATA messages in the kernel log regarding what is done with my disks way more clear. So Alan, Robert, everybody else who helped me with migrating to libsata from the old IDE drivers, thanks a lot, your help was and is highly appriciated. Patrick - 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: hdparm for lib_pata
On 2/5/07, Robert Hancock <[EMAIL PROTECTED]> wrote: Patrick Ale wrote: The southbridge usually runs the PCI bus connected to the slots, so it's possible that PCI bus issues were causing problems.. Explains a lot then yeah... okay, if the error occures again I will let you know, I am booting up as we speak :) - 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: More pata_ stuff
Hi, It is working since I enabled this ATA_PIIX driver. :) Appearantly "old" has nothing to do with the age of the mainboard and it's capabilities. an UDMA33 board works with the "new" driver even :) Thanks a lot, next beer/slivovica/palinka is on me :) Patrick - 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: hdparm for lib_pata
Good morning all, About the reason as of why it drops to PIO mode, I might have found the reason for this, I am just not sure if what i found is related. When I opened my Athlon XP machine, took the cables out and replaced them for new cables, I found out that my southbridge fan wasnt spinning anymore, at all. So my guess is that this chip is overheated at some point and starts causing problems. Now, it was always my comprehension that the southbridge does indeed control the ATA controller but only the onboard one, so even if the chip is having heat problems, my PCI add-on cards should still work on full UDMA100 speed, right? I am re-assembling my athlon board again today, and as soon as I get the falling back to PIO mode errors again in dmesg I'll forward you the messages, like you asked :) If someone could shine a light on my question about the southbridge, I'd really appriciate it, email me privately if you prefer. Thanks! Patrick - 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: More pata_ stuff
It's working, thanks :) I was confused by this ATA_PIIX driver needing to be enabled, I genuinly thought and read it was the SATA driver. Thanks :) - 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: More pata_ stuff
On 2/4/07, Patrick Ale <[EMAIL PROTECTED]> wrote: On 2/4/07, Alan <[EMAIL PROTECTED]> wrote: \ > OLDPIIX is for "old" PIIX devices only - from pentium era. It does not > cover the later chips at all Just to make sure, this is a P2 SMP board, Slot A, doesnt even support P3 CPUs. The board is something like, 5 years old or so. Which driver *should* work for me? The board even has *gasp* ISA slots and doesnt support anything more than UDMA33 :D - 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: More pata_ stuff
On 2/4/07, Alan <[EMAIL PROTECTED]> wrote: \ OLDPIIX is for "old" PIIX devices only - from pentium era. It does not cover the later chips at all Well, neither driver works, as you can see in my config I have the "OLD" driver and the "new" driver, neither driver makes my controller being detected... Patrick - 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: More pata_ stuff
On 2/4/07, Patrick Ale <[EMAIL PROTECTED]> wrote: Amm, not to sound like a wise guy but... CONFIG_ATA_PIIX is the SATA driver, not the PATA driver.. atleast that is what menuconfig tells me when I select "Help" when I look at the config options - 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: More pata_ stuff
On 2/4/07, Alan <[EMAIL PROTECTED]> wrote: PATA_OLDPIIX drives the PIIX (the original not PIIX3,4, etc) People do find that confusing so if there is any rewording for Configure.help that would have made it easier and more obvious let me know Okay so.. what do I define now to use libsata with this controller? I thought PATA_OLDPIIX would be it, like it is just that for VIA,SIL and Promise. And, maybe its a good idea to make it so that if you select PATA_OLDPIIX it automaticly selects the dependencies aswell? I see this happen a lot with other kernel things, like V4L2 and so. Obviously just selecting PATA_OLDPIIX makes you have a half-configured kernel config for this controller, and i used "make menuconfig", I didnt manually edit the .config file. - 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: More pata_ stuff
On 2/4/07, Alistair John Strachan <[EMAIL PROTECTED]> wrote: Which for a PIIX4 chipset is what you want. Somewhat confusingly: CONFIG_PATA_MPIIX=y CONFIG_PATA_OLDPIIX=y Should be "n", I've been told. What? No, this cant be. CONFIG_PATA_OLDPIIX is supposed to be the libsata version for the PIIX IDE driver, which is what i want to use. CONFIG_ATA_PIIX is the old IDE driver, not the pata_ driver, is it? - 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/
More pata_ stuff
Hi, I tried to use the new pata drivers on a Dual PII-400Mhz with the Intel PIIX controller. Unfortunately the controller doesn't get detected on boot time, the old IDE drivers do work and see the controller as a PIIX4 chipset, which is correct. The mainboard is a Asus P2B with integrated Adaptec SCSI host and the PIIX controller. Patrick - 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: hdparm for lib_pata
On 2/4/07, Stephen Clark <[EMAIL PROTECTED]> wrote: I have had two different laptops that had to have boot time command line overrides to get the driver to allow the hardware work at what it was spec-ed at. Well, I am sure that someone will at least take the problem I have serious and will give me a good alternative to get things working, which isnt always the case with mickeysoft :D But again, yes, I do agree that if someone/something decides to reduce my transferspeed I should have an option to override that decision or tell the thing not to make that decision. Patrick - 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: hdparm for lib_pata
On 2/4/07, Stephen Clark <[EMAIL PROTECTED]> wrote: Robert Hancock wrote: But why are we taking away the users capability to control his/her own hardware. Sounds like windows. I wouldn't go as far as making that comparsion, most of all cause it's totaly invalid, with all respect. In my opinion the new pata drivers are work in progress, they only appear in the latest kernel and snapshots so please, let's allow the drivers to evolve, I am no kernel hacker or coder, nor does my interest lay here at the moment to be honest, I am a system administrator working with Unix and Linux and am interested in helping out where I can. By using the new pata drivers in favor of the old IDE drivers I took a risk, well calculated and with the very thought of encountering these kind of problems and reporting them to make things better. However, I do have to agree with the point that if the drivers/kernel, for whatever reason they might have, to switch to a lower UDMA mode, and when none is left, even to PIO mode, I should have at least the chance to switch back to a higher level of datatransfer speed. How it looks now is that the kernel and its drivers treat the devices as ATA devices with their features, but the userland programs like hdparm and sdparm and blkutil see the devices as SCSI/SATA devices, and dont allow the ioctl commands which are valid for ATA drives. Just my two euros/canadian dollars/croatian kunas in the pocket :) Patrick - 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: hdparm for lib_pata
Hi, The problem is even worse, the drive falls back to PIO mode and there is no way I can get it back to dma mode (like I could by using hdparm). The only thing i can do is reboot the machine so it will see the drive is UDMA capable. If there is some beta/gamma software around or something you'd like to have tested, you can mail me directly, my machine is your private prostitute at the moment, it's not like i have something important to do with the machine anyway (not related to this problem):) Patrick - 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/
hdparm for lib_pata
Hi guys, Me again, sorry. Is it possible to make hdparm work with libata? I have some drives that for some reason fall back to lower UDMA settings (like UDMA/44) while the drive is UDMA/100. I blame the way I set-up my raid arrays for this and the bus not being able to handle all the data that goes trough it but that isnt really the case now. Anyway, I used to be able to force the drive back with using hdparm -X68 -d 1 /dev/sdk But with the new lib_pata drivers I get "Inappropriate iotcl for device" and HD_IO_DRIVE_CMD Input/Output errors. Or! Is there some other way to force the drive not to failback to lower UDMA settings? (Yep, I know, if this is answer, it's my risk, I cant and wont blame you for destructing my pr0n or severe trauma I suffer from losing data) Patrick - 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: Boot problems with pata_via driver
On 1/29/07, Patrick Ale <[EMAIL PROTECTED]> wrote: A lot of crap. And i am a fruitcake, nutter, headcase. *sigh* sorry for wasting your time, I found my problem. Since I thought libata worked like my old ata drivers and 2.6.19 was booting well, I reconfigured my kernel source and changed CONFIG_BLK_DEV=y to CONFIG_BLK_DEV=m, since I genuinely thought I wouldnt need additional disk drivers since I never needed them for IDE. I compiled the kernel and all but never copied over the bzImage over to /boot/ Now, I grabbed the config from 2.6.19 , copied it to 2.6.20, ran a make oldconfig && make && make_modules and copied the bzImage to /boot/. Of course, the 2.6.20 image I try to boot DOES contain the CONFIG_BLK_DEV=m , so it wont find any disks, since the module is not active (I dont use ramdisks). I reconfigured 2.6.20 with CONFIG_BLK_DEV=y , and its working now. idiot I am, what else can I say. Again, sorry for wasting your time. - 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: Boot problems with pata_via driver
On 1/29/07, Patrick Ale <[EMAIL PROTECTED]> wrote: Okay so, I unplugged the keyboard the moment I selected a kernel to boot. The last thing i see on my screen, regarding SCSI is: scsi 0:0:0:0: Direct-Access ATA WDC WD2000JB-00G 08.0 PQ: 0 ANSI: 5 scsi 1:0:0:0 CD-ROM AOPEN DUW1608/ARR A060 PW: 0 ANSI: 5 Funny, when I look at my dmesg log when I boot the 2.6.19 kernel (which works) then I seem to miss something in the kernel output when I boot the 2.6.20 kernel. When I boot 2.6.19 I see: scsi 0:0:0:0: Direct-Access ATA WDC WD2000JB-00G 08.0 PQ: 0 ANSI: 5 SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sda4 < sda5 sda6 > sd 0:0:0:0: Attached scsi disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 Does 2.6.20 see my IDE bus but it doesnt probe for drives? Patrick - 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: Boot problems with pata_via driver
Okay so, I unplugged the keyboard the moment I selected a kernel to boot. The last thing i see on my screen, regarding SCSI is: scsi 0:0:0:0: Direct-Access ATA WDC WD2000JB-00G 08.0 PQ: 0 ANSI: 5 scsi 1:0:0:0 CD-ROM AOPEN DUW1608/ARR A060 PW: 0 ANSI: 5 then later on: VFS: Cannot open root device "sda3" or unknown-block(0,0) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) - 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: Boot problems with pata_via driver
On 1/29/07, Patrick Ale <[EMAIL PROTECTED]> wrote: On 1/29/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Sun, Jan 28, 2007 at 12:47:18PM +0100, Patrick Ale wrote: > > Hi Patrick, Morning! The 2.6.19 was self-compiled, using the gentoo-sources-rc4 AND using the vanilla 2.6.19 from kernel.org (I was recommended to use vanilla sources with my ATI drivers), both worked. 2.6.20 is self compiled to. I will give you the kernel output when I am at home, I will have to connect a serial cable to my laptop and use the scrollbuffer since on a kernel panic or system crash my keyboard leds start to blink, which the kernel sees as a device addressing hardware directly and giving me a kernel message for every blink :D Oh, and pata_via is the ONLY driver I have compiled built-in, regarding libsata. As I mentioned in previous mails I have quite some controllers and disks, but pata_via (my onboard IDE) has only two drives attaches, on IDE0 (in 2.6.19 ata0) my boot disk I also tried to boot with scsi_mod.scan=sync, this didnt work either More info follows, thanks for your time allready :) Patrick - 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/
Boot problems with pata_via driver
Hi, With kernel 2.6.19 I was able to boot using the pata_via driver I tried to compile 2.6.20-rc6 and now I get a "unknown device: sda3" error when I try to boot. I compiled 2.6.20-rc6 by copying over the .config from the 2.6.19 tree and running a make oldconfig && make Am I doing something wrong? Patrick - 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/
pata_sil680 module, udev and changing drive node order
Hi all, I am using kernel 2.6.19 with the new pata and sata drivers. First of all, the drivers work great, no crashes nothing. There is one downside i found by using these drivers, and i am not sure how i can fix this. The drivers load correctly but my drives seem to be in a different order all the time, which is not very convinient when your run md devices. I have a pata_via driver, which is built-in to the kernel since it serves my primary and secundary ATA controller. I have a pata_pdc2027x driver, serving the 3rd and 4th ATA controller on the motherboard. (as module) I have a pata_sil680 driver serving 2 PCI add-in cards (as module) I have a sata_sil driver for the onboard sata controller. (as module) What seems to happen is that either the modules are auto-loaded and that the pata_sil680 driver changes the order of the two PCI cards every reboot or that udev gets different events from different controllers as first after every reboot and therefor creates the device nodes different. So, my question is: how do I force a fixed order for a module handling two PCI cards, or how do I tell udev to always use the same mapping for the device nodes in /dev? Thanks, - 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/
