Re: Is a new EPOLLCLOSED a solution to the problem that EPOLL_CTL_DISABLE tried to solve?
y EPOLLCLOSED) has been returned by an epoll_wait() no other events may be returned for that fd. This is obvious, and should be easy to implement. I just added it for completeness ;). > But this case is fairly straightforward with the user mode approach -- > for example, add it to the list for all threads calling epoll_wait. > Or otherwise defer the deletion until all epoll_wait threads have > woken. That really seems a hell of lot more complex (involving mutexes and updating a queue that might grow till unknown sizes, hence requiring possibly calls to malloc) then my proposed solution, for something that basically every application that uses epoll needs. -- Carlo Wood
On
d there are no readers, and the grace period can finish instantly, simply because there is no way to register that data.ptr was already copied. If one tries to begin a read-side critical area after epoll_wait() returns, then that won't work: in that case you should not be able to access that ptr when it was already removed from the interest list. The only way that RCU would work here is when a reader subscribes *before* the kernel copies the corresponding epoll_event structure to user space, in a way that that will never happen when the EPOLL_CTL_DEL finished before it got to that point. I believe that the only safe solution is to let the Event Loop Thread do the deleting. So, if all else fails I'll have to add objects that a Worker Thread thinks need to be deleted to a FIFO that is processed by the Event Loop Thread before entering epoll_wait(). But that is a lot of extra code for something that could be achieved with just a small change to epoll: I propose to add a new EPOLL event EPOLLCLOSED that will cause epoll_wait to return (for that event) whenever a file descriptor is closed. The Worker Thread then does not remove an object from the interest list, but either adds (if it was removed before) or modifies the event (using EPOLL_CTL_MOD) to watch that fd for closing, and then closes it. Aka, Working Thread: epoll_ctl(epoll_fd, EPOLL_CTL_ADD, fd, &event); close(fd); where event contains the new EPOLLCLOSED (compare EPOLLOUT, EPOLLIN etc). This must then guarantee the event EPOLLCLOSED to be reported by exactly one epoll_wait(), the caller thread of which can then proceed with deleting the resources. Note that close(fd) must cause the removal from the interest list of any epoll struct before causing the event - and that the EPOLLCLOSED event may only be reported after all other events for that fd have already been reported (although it would be ok to report them at the same time: simply handle the other events first). I am not sure how this will work when more than one thread calls epoll_wait and more than one watch the same fd: in that case it is less trivial because then it seems always possible that the EPOLLCLOSED event will be reported before another event in another thread. What are your thoughts? Is the addition of EPOLLCLOSED event feasible? -- Carlo Wood
Re: PROBLEM: MacBook makes whining noise when usb-uhci active
On Sun, Jul 08, 2007 at 12:41:55AM -0400, Tim Hull wrote: > After reading the ThinkPad wiki link, I've found that the problem has > to do with the C3 and C4 ACPI states. I'm guessing that the 2.6.18 > kernel I was using on Debian Etch just happened to not support full > power management on my MacBook - hence, the problem didn't occur. > > Sorry for all of this - I guess I'll pass this info on to Apple and > see if they may be able to fix this with a firmware update (it occurs > on OS X too). The most likely source of a noise as you seem to describe is a ceramic capacitor. An alternative is some coil, but that you usually only hear in cases where a high frequency is used inside a voltage convertor (in order to reduce transformator or coil sizes) and I doubt that anything like that is possible in a laptop... I'd have the hear the actual sound to know what it is. 99% chance it's a ceramic capacitor that has to absorb some pulsed current. If you'd replace the capacitor with another one of a different type (same capacity, of course), for example a styroflex one, then the noise would go away. It's very difficult to find out which it is however ;). The only method that I know is by touching each capacitor (ie with pliers) while it is making noise, which will cause the sound to change a little if you have the right one. -- Carlo Wood <[EMAIL PROTECTED]> - 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: Is it time for remove (crap) ALSA from kernel tree ?
On Sat, Jul 07, 2007 at 02:41:05AM +, William Pitcock wrote: > The most fucked up thing that I can think of about the current state of > affairs in ALSA is dmix. Every other UNIX sound system like ALSA does it's > software mixing in kernel space. The applications never even know about > it. It's not only until recently (2005-2006 or so) that ALSA came close to > this, but there are still problems. Many cards need workarounds to make > dmix work because of the way it works, and the way that ALSA buffers data > around. I have to agree. I am not an audio programmer, just a user; but the bottom line is simply: It is WAY to hard to get things working (if at all possible). At one point I tried to get sound from xmms and ut2004 at the same time (on my new machine). I was ASTONISHED that it didn't Just-Work! After trying many complex things-- I gave up and put my old soundblaster Live! in the new PC - because that card has hardware support for this. Now I was lucky to HAVE that other soundcard, but what about all those other users out there who just buy a new PC, with a sound chip on the motherboard and then, being simple, ordinairy users, have to face this ALSA configuration hell to do something as simple as having two audio applications play sound at the same time? > For the non-technically inclined, ALSA only keeps two fragments for > input/output data each. This is horribly unusable because most soundcard > fragments are only 1KB, so applications have to adopt ringbuffers to pass > data to ALSA. If you're doing video, this leads to possible timing issues > unless you sit down and well design your abstraction layer for audio I/O. Worse-- the two fragment limit is passed on to the OSS emulation (or at least it was in 2005; but if this is still true for the ALSA API in 2007, then my guess is that it's also still true for the OSS emulation). The result is that applications written for OSS do not work anymore when using the OSS emulation of ALSA and therefore the argument of providing backwards compatibility doesn't exist. ...snip... > Hannu has ideas on how that could work. I suggest all of the kernel > developers listen, and listen well, or this mess will never be fixed in a > way that is truly usable. > > -nenolod Good post, nenolod. -- Carlo Wood <[EMAIL PROTECTED]> PS I am NOT saying that I want ALSA to be removed from the kernel. I am just saying that I agree with those who think that the ALSA API is too complex, hard to use and has serious flaws that should be addressed. - 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: NVidia Driver Support - 1680x1050 mode
Or use the same hardware as me (and debian)-- and read on my home page how I got things working :p hikaru:/usr/lib>dpkg -l | grep nvidia ii nvidia-glx 100.14.11-0 NVIDIA binary Xorg driver ii nvidia-glx-dev 100.14.11-0 NVIDIA binary Xorg driver development files ii nvidia-kernel-2.6-amd64 100.14.11+beta NVIDIA binary kernel module for 2.6 series c ii nvidia-kernel-2.6.18-4-amd64 100.14.11+beta NVIDIA binary kernel module for Linux 2.6.18 ii nvidia-kernel-2.6.22-rc5-agp1-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64 100.14.11+beta NVIDIA binary kernel module for Linux 2.6.22 -- Carlo Wood <[EMAIL PROTECTED]> PS I use two of my Samsung SyncMaster 205BW (1650x1050) as dual head on an ASUS EN8600 GTS (dual-head). You need nvidia's beta drivers (>= 100.14.06) for that to work though. - 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 Harddisk speed drop of 100 MB/s
On Mon, Jun 25, 2007 at 11:18:41AM -0400, Lennart Sorensen wrote: > How do you know 165MB/s is correct? It is the maximum value I measure. It's also the value that I measure consistently with NCQ off, like with 2.6.18. Finally, even before I bought this PC, I did some research and the RAID with Raptors was recommended by someone with a lot of experience with them. He told me that I could count on (N - 1) * 75 MB/s (on average) for an array with N disks. I had expected 150 MB/s, which is about what I get. The 165 MB/s is on the outside of the disk (low partition). -- Carlo Wood <[EMAIL PROTECTED]> - 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: Is it time for remove (crap) ALSA from kernel tree ?
On Mon, Jun 25, 2007 at 12:48:45AM +0200, Jesper Juhl wrote: > Did you try resending it? > Sometimes patches get missed, overlooked, dropped on the floor by mistake > etc. ... > When it comes to getting patches into mainline, asking twice (or more) > is sometimes required, and it's considered your responsability as > submitter to resend a patch if noone reacts to it the first time > around. Some history: At the time I suffered from a severe RSI (Repitive Stress Injury) and I had to take into account that I'd not be able to type anymore at some point. This is why I became interested in speech recognition, even though I had to limit my typing time to 2 hours or so per day. The only speech recognition software available for linux was 'ViaVoice', a discontinued package sold by IBM. I managed to get my hand on one (even though they aren't even sold anymore *cough cough*) and quickly found out that it was so old that it didn't even run anymore. I hacked the binary package (closed source and stuff) until it ran again (which involved writing this kernel patch). However, then I found out that ViaVoice was unusable for me: it didn't recognize my voice - it just didn't work (it worked for others, so it much be my voice or accent or whatever). Hence, I dropped the whole project. I could use my two hours per day of typing better. Now - about the resending the patch... I usually do, but I also reschedule the priority of such a task. In this case, since I NEVER do anything with recording - and the project that made me be involved was dead as far as me was concerned - it got scheduled so far at the bottom that I simply never got to it anymore. I have no idea how much the code has changed in the meantime, but the problem is/was this: There is significant difference between ALSA and OSS such that an application that works under OSS does not work anymore with the OSS emulation under ALSA. Firstly, the total recording buffer that you get is limited - while that is not the case with OSS. Secondly, if that buffer runs full (xrun) the stream is stopped permanently and not restarted, while it is restarted with OSS. You can download testcode.c from http://www.xs4all.nl/~carlo17/alsa/index.html and run it: hikaru:~>./a.out Allocated 2 buffers of 1024 bytes. Allocated 2 buffers of 2048 bytes. Allocated 2 buffers of 4096 bytes. Successfully allocated a buffer that is large enough. Available bytes: 3072 Available bytes: 4768 Available bytes: 6432 Available bytes: 8192 Successfully caused an xrun. non-blocking fragments: 2 non-blocking bytes: 8192 Available bytes in buffer: 9856 Additionally read 1024 bytes. Additionally read 1024 bytes. Additionally read 1024 bytes. Additionally read 1024 bytes. Additionally read 1024 bytes. Additionally read 1024 bytes. Stream is not restarted after xrun. Since this is not the same behaviour as with OSS - I think it's a bug. I don't know if the patch on that patch can still be applied, but if not - then I'm sure you are more into that code than me and it will be a lot easier for you to fix this the right way in the correct kernel code :) -- Carlo Wood <[EMAIL PROTECTED]> - 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: Is it time for remove (crap) ALSA from kernel tree ?
On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote: > > Sory Alan but I don't want philosophical/historical discuss. > > Try to answer on question "ALSA or OSS ?" using *only* technical arguments. > > We dropped OSS for ALSA for technical reasons. Those being that ALSA > - has a better audio API > - is more flexible > - provides OSS as emulation > - supports more hardware I sent a patch to the ALSA developers 4 years ago. It was never included in the kernel :/ Here's the comment from a script that I once wrote to make some closed-source dinosar code run (speech recognition) on modern linux: # Note that ALSA (Advanced Linux Sound Architecture), the sound drivers that # replace the older OSS as of kernel 2.5, also introduce a problem for some # soundcards: unlike the OSS drivers, the ALSA drivers limit the recording # buffer to the hardware limit of your sound card. For example, the SB Live! # only has two 'period' buffers (called fragments before), and although # viavoice requests an 'arbitrary number of periods, size 1024 bytes', it # only gets two periods of 1024 bytes: 2048 bytes in total! The ViaVoice # engine however doesn't even process sound until it sees at least 6102 bytes. # The 'solution' for this is to increase the buffer size (from 1024 to say # 8192), this script also takes care of that. Unfortunately, also that is # possibly not enough: the sound is read from the hardware in chunks of # 'period size' and having only two buffers this is often causing an underrun. # When ALSA sees an underrun... it stops the sound stream. My (four year old) patch can be found here: http://www.xs4all.nl/~carlo17/alsa/index.html I STILL think that ALSA should restart the stream after an underrun, but I am not someone who asks twice :p usually. -- Carlo Wood <[EMAIL PROTECTED]> - 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 RAID5 speed drop of 100 MB/s
On Sun, Jun 24, 2007 at 12:59:10PM -0400, Justin Piszcz wrote: > Concerning NCQ/no NCQ, without NCQ I get an additional 15-50MB/s in speed > per various bonnie++ tests. There is more going on than a bad NCQ implementation of the drive imho. I did a long test over night (and still only got two schedulers done, will do the other two tomorrow), and the difference between a queue depth of 1 and 2 is DRAMATIC. See http://www.xs4all.nl/~carlo17/noop_queue_depth.png and http://www.xs4all.nl/~carlo17/anticipatory_queue_depth.png The bonnie++ tests are done in a directory on the /dev/md7 and /dev/ssd2 partitions respectively. Each bonnie test is performed four times. The hdparm -t tests (that show no difference with a -tT test) are each done five times, for /dev/sdd, /dev/md7 and /dev/sda (that is one of the RAID5 drives used for /dev/md7). Thus in total there are 2 * 4 + 3 * 5 = 23 data points per queue depth value in each graph. The following can be observed: 1) There is hardly any difference between the two schedulers (noop is a little faster for the bonny test). 2) An NCQ depth of 1 is WAY faster on RAID5 (bonnie; around 125 MB/s), the NCQ depth of 2 is by far the slowest for the RAID5 (bonnie; around 40 MB/s). NCQ depths of 3 and higher show no difference, but are also slow (bonnie; around 75 MB/s). 3) There is no significant influence of the NCQ depth for non-RAID, either the /dev/sda (hdparm -t) or /dev/sdd disk (hdparm -t and bonnie). 4) With a NCQ depth > 1, the hdparm -t measurement of /dev/md7 is VERY unstable. Sometimes it gives the maximum (around 150 MB/s), and sometimes as low as 30 MB/s, seemingly independent of the NCQ depth. Note that those measurement were done on an otherwise unloaded machine in single user mode; and the measurements were all done one after an other. The strong fluctuation of the hdparm results for the RAID device (while the underlaying devices do not show this behaviour) are unexplainable. >From the above I conclude that something must be wrong with the software RAID implementation - and not just with the harddisks, imho. At least, that's what it looks like to me. I am not an expert though ;) -- Carlo Wood <[EMAIL PROTECTED]> PS RAID5 (md7 = sda7 + sdb7 + sdc7): Three times a Western Digital Raptor 10k rpm (WDC WD740ADFD-00NLR1). non-RAID (sdd2): Seagate barracuda 7200 rpm (ST3320620AS). The reason that now I measure around 145 MB/s instead of 165 MB/s as reported in previous post (with hdparm -t /dev/md7) is because before I use hdparm -t /dev/md2, which is closer to the outside of the disk and therefore faster. /dev/md2 still is around 165 MB/s. - 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: How innovative is Linux?
On Sat, Jun 23, 2007 at 04:46:08PM +0100, Alan Cox wrote: > Now if you want really innovative OS work go look in the lab or at > projects most people have never heard of and don't run. Hey, I heard of one. I got a few friends that are sitting in an IRC channel and have been working on a complete new OS from scratch for like 10 years now (kernel, filesystem, graphics drivers, libraries - everything). I consider them to be totally nuts of course. When I ask them why are you still doing this? Can't you use linux? Then the answer is that there are still companies interested in operating systems like that, precisely because they are not well- known. It would be pretty hard to exploit vulnerabilities in such a system (or that is their explanation anyway). -- Carlo Wood <[EMAIL PROTECTED]> - 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 RAID5 speed drop of 100 MB/s
On Sat, Jun 23, 2007 at 03:03:33AM -0400, Jeff Garzik wrote: > Your disk configurations are quite radically different between the two > kernels (see attached diff for key highlights). > > The new behavior of the more recent kernel (551c012d7...) is that it now > fully drives your hardware :) The reset problems go away, NCQ is > enabled, and if you had 3.0Gbps drives (you don't) they would be driven > at a faster speed. > > Given that some drives might be better tuned for benchmarks in > non-queued mode, and that a major behavior difference is that your > drives are now NCQ-enabled, the first thing I would suggest you try is > disabling NCQ: > http://linux-ata.org/faq.html#ncq Thanks! That is indeed the difference that causes the drop of "hdparm -tT" that I observed. After setting /sys/block/sdX/device/queue_depth of all three drives to 1, I get again /dev/md2: Timing cached reads: 8252 MB in 2.00 seconds = 4130.59 MB/sec Timing buffered disk reads: 496 MB in 3.01 seconds = 164.88 MB/sec on 2.6.22-rc5. > Other indicators are the other changes in the "ahci :00:1f.2: > flags:" line, which do affect other behaviors, though none so important > to RAID5 performance as NCQ, I would think. > > Turning on NCQ also potentially affects barrier behavior in RAID, though > I'm guessing that is not a factor here. Of course, I am not really interested in what "hdparm -tT" gives, but rather in a high performance during real-life use of the disks. Is it possible that the measurement with "hdparm -tT" returns a higher value for some setting, but that the over-all real-life performance drops? Also, the effect of this setting is nil for the individual drives. hdparm -tT /dev/sda gives me still around 65 MB/s. I don't understand why this setting has such a HUGE effect on RAID5 while the underlaying drives themselves don't seem affected. PS I'd like to do extensive testing with Bonnie++ to tune everything there is to tune. But bonnie likes to write/read files TWICE the amount of RAM I have. It therefore takes a LOT of time to run one test. Do you happen to know how I can limit the amount of RAM that the linux kernel sees to, say 500 MB? That should be enough to run in Single User mode but allow me to run the tests MUCH faster. (I have dual channel, four DIMM's of 1 GB each -- 2 GB per Core 2 die. Hopefully the fact that I have dual channel isn't going to be a problem when limiting the ram that the kernel sees.) -- Carlo Wood <[EMAIL PROTECTED]> - 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 RAID5 speed drop of 100 MB/s
For what it's worth... I tried applying --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -516,6 +516,8 @@ static void ahci_save_initial_config(struct pci_dev *pdev, * reset. Values without are used for driver operation. */ hpriv->saved_cap = cap = readl(mmio + HOST_CAP); + hpriv->saved_cap &= ( (1<<28) | (1<<17) ); + hpriv->saved_cap |= (1 << 27); hpriv->saved_port_map = port_map = readl(mmio + HOST_PORTS_IMPL); /* some chips lie about 64bit support */ to 2.6.22-rc5, but it had no effect :*) I'll await any comments from a kernel developer for now. Please let me know if you want me to test something. -- Carlo Wood <[EMAIL PROTECTED]> - 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 Harddisk speed drop of 100 MB/s
On Fri, Jun 22, 2007 at 10:31:32PM -0300, Henrique de Moraes Holschuh wrote: > for i in /sys/block/sd*/queue/scheduler ; do echo -n "scheduler for $i was:" > ; cat $i ; echo anticipatory > $i ; done > > Should show you the scheduler for all libata/scsi discs, and switch to > anticipatory. It probably works for hd* as well, but I don't have any > around to test. > > I had ridiculous md raid performance (on resync) using cfq at least once. > Unfortunately I never bothered trying to track it down, and I didn't check > the throughput after the resync was done either. Also, I don't recall the > kernel version, but it was either 2.6.18 or 2.6.20. Just one kernel version? The problem here is in every kernel revision after 551c012d7eea3dc5ec063c7ff9c718d39e77634f 2.6.20-rc2,rc3,rc4,rc5,rc6,rc7 ... 2.6.20 ... 2.6.21 ... 2.6.22-rc5 noop: Timing buffered disk reads: 254 MB in 3.00 seconds = 84.66 MB/sec anticipatory: Timing buffered disk reads: 252 MB in 3.02 seconds = 83.43 MB/sec deadline: Timing buffered disk reads: 258 MB in 3.02 seconds = 85.41 MB/sec cfq: Timing buffered disk reads: 194 MB in 3.03 seconds = 64.06 MB/sec The normal value is cfq. So, all other schedulars are somewhat faster, but still far from the correct 165 MB/s. -- Carlo Wood <[EMAIL PROTECTED]> - 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 RAID5 speed drop of 100 MB/s
The dmesg output of 33480a0ede8dcc7e6483054279008f972bd56fd3 (thus "before") is: == Linux version 2.6.20-rc1-bisect-33480a0ede8dcc7e6483054279008f972bd56fd3-amd64 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Jun 22 22:13:01 CEST 2007 Command line: root=/dev/md2 ro agp=off single BIOS-provided physical RAM map: BIOS-e820: - 0009ec00 (usable) BIOS-e820: 0009ec00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 7ff9 (usable) BIOS-e820: 7ff9 - 7ff9e000 (ACPI data) BIOS-e820: 7ff9e000 - 7ffe (ACPI NVS) BIOS-e820: 7ffe - 8000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) BIOS-e820: 0001 - 00018000 (usable) Entering add_active_range(0, 0, 158) 0 entries of 3200 used Entering add_active_range(0, 256, 524176) 1 entries of 3200 used Entering add_active_range(0, 1048576, 1572864) 2 entries of 3200 used end_pfn_map = 1572864 DMI 2.4 present. ACPI: RSDP (v002 ACPIAM) @ 0x000fae40 ACPI: XSDT (v001 ÿÿ 0x03000709 MSFT 0x0097) @ 0x7ff90100 ACPI: FADT (v003 MSTEST OEMFACP 0x03000709 MSFT 0x0097) @ 0x7ff90290 ACPI: MADT (v001 MSTEST OEMAPIC 0x03000709 MSFT 0x0097) @ 0x7ff90390 ACPI: MCFG (v001 MSTEST OEMMCFG 0x03000709 MSFT 0x0097) @ 0x7ff90400 ACPI: SLIC (v001 ÿÿ 0x03000709 MSFT 0x0097) @ 0x7ff90440 ACPI: OEMB (v001 MSTEST AMI_OEM 0x03000709 MSFT 0x0097) @ 0x7ff9e040 ACPI: HPET (v001 MSTEST OEMHPET 0x03000709 MSFT 0x0097) @ 0x7ff99440 ACPI: DSDT (v001 A0483 A0483035 0x0035 INTL 0x20060113) @ 0x No NUMA configuration found Faking a node at -00018000 Entering add_active_range(0, 0, 158) 0 entries of 3200 used Entering add_active_range(0, 256, 524176) 1 entries of 3200 used Entering add_active_range(0, 1048576, 1572864) 2 entries of 3200 used Bootmem setup node 0 -00018000 Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1572864 early_node_map[3] active PFN ranges 0:0 -> 158 0: 256 -> 524176 0: 1048576 -> 1572864 On node 0 totalpages: 1048366 DMA zone: 56 pages used for memmap DMA zone: 972 pages reserved DMA zone: 2970 pages, LIFO batch:0 DMA32 zone: 14280 pages used for memmap DMA32 zone: 505800 pages, LIFO batch:31 Normal zone: 7168 pages used for memmap Normal zone: 517120 pages, LIFO batch:31 ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) Processor #2 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) Processor #3 ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 4, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to physical flat ACPI: HPET id: 0x8086a202 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Nosave address range: 0009e000 - 0009f000 Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000e4000 Nosave address range: 000e4000 - 0010 Nosave address range: 7ff9 - 7ff9e000 Nosave address range: 7ff9e000 - 7ffe Nosave address range: 7ffe - 8000 Nosave address range: 8000 - fee0 Nosave address range: fee0 - fee01000 Nosave address range: fee01000 - ffb0 Nosave address range: ffb0 - 0001 Allocating PCI resources starting at 8800 (gap: 8000:7ee0) SMP: Allowing 4 CPUs, 0 hotplug CPUs PERCPU: Allocating 36992 bytes of per cpu data Built 1 zonelists. Total pages: 1025890 Kernel command line: root=/dev/md2 ro agp=off single Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Checking aperture... Calgary: Unable to locate Rio Grande Table in EBDA - bailing! PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Placing software IO TLB between 0x1655000 - 0x5655000 Memory: 4024892k/6291456k available (1963k kernel code
Re: SATA Harddisk speed drop of 100 MB/s
On Fri, Jun 22, 2007 at 06:17:46PM -0300, Henrique de Moraes Holschuh wrote: > On Fri, 22 Jun 2007, Carlo Wood wrote: > > So far I found out that it's RAID only. > > If you change the IO schedulers, does it help? How do I do that? -- Carlo Wood <[EMAIL PROTECTED]> - 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 Harddisk speed drop of 100 MB/s
On Wed, Jun 20, 2007 at 08:36:52PM -0700, Arjan van de Ven wrote: > also do a > > echo 60 > /proc/sys/vm/dirty_ratio > > first to see if that helps That makes no difference. It took a while before I replied - because I first want to do a bisect to find a version closer to the problem. So far I found out that it's RAID only. I have four disks: Three times a western digital Raptor 10k rpm: ATA device, with non-removable media Model Number: WDC WD740ADFD-00NLR1 Firmware Revision: 20.07P20 And one Seagate Barracuda 7200 rpm: ATA device, with non-removable media Model Number: ST3320620AS Firmware Revision: 3.AAE The Raptors are in RAID5. hdparm -tT gives me always > 4 GB/s cached reads, for example: Timing cached reads: 8166 MB in 2.00 seconds = 4086.82 MB/sec and the buffered disk reads do not significantly vary when reading the devices directly (/dev/sda, /dev/sdb, /dev/sdc for the Raptors and /dev/sdd for the Barracuda): /dev/sda etc: Around 67 MB/sec /dev/sdd: Around 75 MB/sec (so much for 10k rpm ...) These numbers are weird in itself (the 67 should have been 75, and the 75 should have been 54) - but at least they are constant. What DOES *signficantly* change as function of kernel revision is the buffered disk read with hdparm -tT /dev/md2 The normal speed I get is > 160, often 165 MB/sec. But with kernel revisions over a certain version that drops to around 67 MB/sec - and at one point I even observed a drop in speed every time I repeated the measurement until the speed was around 30 MB/s ! At the moment I am (still) doing the bisect; I had some problems compiling a pristine 2.6.18 and some problems with the config (that differs significantly between 2.6.18 and 2.6.22) as well as the problem that the kernel simply didn't compile for a large range of revisions needed for the bisect (I needed to export current_is_keventd with this patch: diff --git a/kernel/workqueue.c b/kernel/workqueue.c index c525731..012e11b 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -654,6 +654,7 @@ int current_is_keventd(void) return ret; } +EXPORT_SYMBOL_GPL(current_is_keventd); /* Take the work from this (downed) CPU. */ static void take_over_work(struct workqueue_struct *wq, unsigned int cpu) ) I'll report back when I'm done with the bisect :) -- Carlo Wood <[EMAIL PROTECTED]> - 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][AGPGART] intel_agp: don't load if no IGD and AGP port
port0, io 0xcc00, speed 1041kHz ACPI: PCI Interrupt :04:02.0[A] -> GSI 23 (level, low) -> IRQ 23 input: PS/2 Logitech Mouse as /class/input/input3 iTCO_wdt: Found a ICH8 or ICH8R TCO device (Version=2, TCOBASE=0x0860) iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) EXT3 FS on md2, internal journal loop: module loaded coretemp coretemp.0: Using undocumented features, absolute temperature might be wrong! coretemp coretemp.1: Using undocumented features, absolute temperature might be wrong! coretemp coretemp.2: Using undocumented features, absolute temperature might be wrong! coretemp coretemp.3: Using undocumented features, absolute temperature might be wrong! device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: [EMAIL PROTECTED] kjournald starting. Commit interval 5 seconds EXT3 FS on md0, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md5, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on sdd2, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on sdd3, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md8, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md3, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md6, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md7, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md4, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on dm-1, internal journal EXT3-fs: mounted filesystem with ordered data mode. Adding 15631096k swap on /dev/mapper/cswap. Priority:1 extents:1 across:15631096k sky2 eth1: enabling interface sky2 eth1: ram buffer 0K NET: Registered protocol family 10 lo: Disabled Privacy Extensions ADDRCONF(NETDEV_UP): eth1: link is not ready sky2 eth1: Link is up at 1000 Mbps, full duplex, flow control both ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready input: Power Button (FF) as /class/input/input4 ACPI: Power Button (FF) [PWRF] input: Power Button (CM) as /class/input/input5 ACPI: Power Button (CM) [PWRB] pnp: the driver 'parport_pc' has been registered lp: driver loaded but no devices found ppdev: user-space parallel port driver Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory NFSD: starting 90-second grace period eth1: no IPv6 routers present Hmm, the dmesg stops here... Perhaps I should have captured it with the serial console. But well, I'll consider it fixed I don't think there was a warning message. If there is then I'll post that later. -- Carlo Wood <[EMAIL PROTECTED]> - 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/
SATA Harddisk speed drop of 100 MB/s
hdparm -tT gives over 160 MB/s for my tripple 10k rpm Raptor RAID5 on 2.6.18, as expected. In 2.6.22-rc5 this dropped to only 60 MB/s ! Is this a known issue? I also measured it with bonnie; I get 108 MB/s reading speed on 2.6.18 and only 68 MB/s on 2.6.22-rc5. -- Carlo Wood <[EMAIL PROTECTED]> - 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.22-rc5 regression
388/975904 blocks done. EXT3 FS on md2, internal journal Setting the system clock.. Cleaning up ifupdown Loading kernel modules...loop: module loaded coretemp coretemp.0: Using undocumented features, absolute temperature might be wrong! coretemp coretemp.1: Using undocumented features, absolute temperature might be wrong! coretemp coretemp.2: Using undocumented features, absolute temperature might be wrong! coretemp coretemp.3: Using undocumented features, absolute temperature might be wrong! done. Loading device-mapper supportdevice-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: [EMAIL PROTECTED] . Generating udev events for MD arrays...done. Starting early crypto disks... cswap(starting) encrypted(starting) Enter LUKS passphrase: key slot 1 unlocked. Command successful. done. Starting remaining crypto disks... cswap(running) encrypted(running)done. Checking file systems...fsck 1.40-WIP (14-Nov-2006) /dev/md0: clean, 48/24096 files, 61709/96256 blocks /dev/md5: clean, 40442/1221600 files, 1029243/2441824 blocks /dev/sdd2: clean, 10111/4889248 files, 5934404/9765511 blocks (check in 3 mounts) /dev/sdd3: clean, 2050/21987328 files, 40298300/43961872 blocks /dev/md8: clean, 116771/2747136 files, 909674/5490144 blocks /dev/md3: clean, 107476/2443200 files, 699836/4883712 blocks /dev/md6: clean, 53/1221600 files, 76570/2441824 blocks (check in 3 mounts) /dev/md7: clean, 1179373/7323648 files, 7577434/14647200 blocks /dev/md4: clean, 8182/732960 files, 293632/1465856 blocks /dev/mapper/encrypted: clean, 14627/1464 files, 13984183/24414646 blocks done. Setting kernel variables...done. Mounting local filesystems...kjournald starting. Commit interval 5 seconds EXT3 FS on md0, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md5, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on sdd2, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on sdd3, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md8, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md3, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md6, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md7, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md4, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on dm-1, internal journal EXT3-fs: mounted filesystem with ordered data mode. done. Activating swapfile swap...Adding 15631096k swap on /dev/mapper/cswap. Priority:1 extents:1 across:15631096k done. Detecting hardware...Setting up networking Configuring network interfaces...done. Starting portmap daemon...sky2 eth1: enabling interface . sky2 eth1: ram buffer 0K NET: Registered protocol family 10 lo: Disabled Privacy Extensions ADDRCONF(NETDEV_UP): eth1: link is not ready Setting sensors limits: done. Setting console screen modes and fonts. Setting up ALSA...done. Recovering schroot sessions: sid32-c84448a9-0a57-4c2a-9a41-c60e0591ba06 sid32-df306a93-1d63-494d-a726-c924190900c6. ^MINIT: Entering runlevel: 2^M Starting system log daemon Starting kernel log daemon Starting portmap daemon...Already running.. Starting HP Linux Printing and Imaging System:sky2 eth1: Link is up at 1000 Mbps, full duplex, flow control both ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready hpiod hpssd. Loading ACPI modules...input: Power Button (FF) as /class/input/input5 ACPI: Power Button (FF) [PWRF] input: Power Button (CM) as /class/input/input6 ACPI: Power Button (CM) [PWRB] . Starting Advanced Configuration and Power Interface daemon Starting BitTorrent tracker: disabled in /etc/default/bittorrent. Starting Common Unix Printing System: cupsdlp: driver loaded but no devices found ppdev: user-space parallel port driver . Starting system message bus: dbus. Starting network connection manager: NetworkManager. Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon. Starting network events dispatcher: NetworkManagerDispatcher. Starting MTA: exim4. Starting mouse interface server: gpm. Starting disk temperature monitoring daemon: hddtemp: /dev/sda /dev/sdb /dev/sdc /dev/sdd.. Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). Exporting directories for NFS kernel daemon Starting NFS kernel daemon: nfsdNFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory NFSD: starting 90-second grace period mountd. Starting internet superserver: inetd. Start
Re: 2.6.22-rc5 regression
ctive with 3 out of 3 mirrors mdadm: /dev/md0 md: md1 stopped. has been started with 3 drives. md: bind md: bind md: bind raid5: device sda2 operational as raid disk 0 raid5: device sdc2 operational as raid disk 2 raid5: device sdb2 operational as raid disk 1 raid5: allocated 3212kB for md1 raid5: raid level 5 set md1 active with 3 out of 3 devices, algorithm 2 RAID5 conf printout: --- rd:3 wd:3 disk 0, o:1, dev:sda2 disk 1, o:1, dev:sdb2 disk 2, o:1, dev:sdc2 mdadm: /dev/md1 md: md2 stopped. has been started with 3 drives. md: bind md: bind md: bind raid5: device sda3 operational as raid disk 0 raid5: device sdc3 operational as raid disk 2 raid5: device sdb3 operational as raid disk 1 raid5: allocated 3212kB for md2 raid5: raid level 5 set md2 active with 3 out of 3 devices, algorithm 2 RAID5 conf printout: --- rd:3 wd:3 disk 0, o:1, dev:sda3 disk 1, o:1, dev:sdb3 disk 2, o:1, dev:sdc3 mdadm: /dev/md2 md: md3 stopped. has been started with 3 drives. md: bind md: bind md: bind raid5: device sda5 operational as raid disk 0 raid5: device sdc5 operational as raid disk 2 raid5: device sdb5 operational as raid disk 1 raid5: allocated 3212kB for md3 raid5: raid level 5 set md3 active with 3 out of 3 devices, algorithm 2 RAID5 conf printout: --- rd:3 wd:3 disk 0, o:1, dev:sda5 disk 1, o:1, dev:sdb5 disk 2, o:1, dev:sdc5 mdadm: /dev/md3 md: md4 stopped. has been started with 3 drives. md: bind md: bind md: bind raid5: device sda6 operational as raid disk 0 raid5: device sdc6 operational as raid disk 2 raid5: device sdb6 operational as raid disk 1 raid5: allocated 3212kB for md4 raid5: raid level 5 set md4 active with 3 out of 3 devices, algorithm 2 RAID5 conf printout: --- rd:3 wd:3 disk 0, o:1, dev:sda6 disk 1, o:1, dev:sdb6 disk 2, o:1, dev:sdc6 mdadm: /dev/md4 md: md5 stopped. has been started with 3 drives. md: bind md: bind md: bind raid5: device sda7 operational as raid disk 0 raid5: device sdc7 operational as raid disk 2 raid5: device sdb7 operational as raid disk 1 raid5: allocated 3212kB for md5 raid5: raid level 5 set md5 active with 3 out of 3 devices, algorithm 2 RAID5 conf printout: --- rd:3 wd:3 disk 0, o:1, dev:sda7 disk 1, o:1, dev:sdb7 disk 2, o:1, dev:sdc7 mdadm: /dev/md5 md: md6 stopped. has been started with 3 drives. md: bind md: bind md: bind raid5: device sda8 operational as raid disk 0 raid5: device sdc8 operational as raid disk 2 raid5: device sdb8 operational as raid disk 1 raid5: allocated 3212kB for md6 raid5: raid level 5 set md6 active with 3 out of 3 devices, algorithm 2 RAID5 conf printout: --- rd:3 wd:3 disk 0, o:1, dev:sda8 disk 1, o:1, dev:sdb8 disk 2, o:1, dev:sdc8 mdadm: /dev/md6 md: md7 stopped. has been started with 3 drives. md: bind md: bind md: bind raid5: device sda9 operational as raid disk 0 raid5: device sdc9 operational as raid disk 2 raid5: device sdb9 operational as raid disk 1 raid5: allocated 3212kB for md7 raid5: raid level 5 set md7 active with 3 out of 3 devices, algorithm 2 RAID5 conf printout: --- rd:3 wd:3 disk 0, o:1, dev:sda9 disk 1, o:1, dev:sdb9 disk 2, o:1, dev:sdc9 mdadm: /dev/md7 md: md8 stopped. has been started with 3 drives. md: bind md: bind md: bind raid5: device sda10 operational as raid disk 0 raid5: device sdc10 operational as raid disk 2 raid5: device sdb10 operational as raid disk 1 raid5: allocated 3212kB for md8 raid5: raid level 5 set md8 active with 3 out of 3 devices, algorithm 2 RAID5 conf printout: --- rd:3 wd:3 disk 0, o:1, dev:sda10 disk 1, o:1, dev:sdb10 disk 2, o:1, dev:sdc10 mdadm: /dev/md8 has been started with 3 drives. Success: assembled all arrays. Done. Begin: Executing udevtrigger again ... Done. Done. Begin: Running /scripts/local-premount ... kinit: name_to_dAttempting manual resume ev_t(/dev/md1) = md1(9,1) kinit: trying to resume from /dev/md1 kinit: No resume image, doing normal boot... kjournald starting. Commit interval 5 seconds Done. EXT3-fs: mounted filesystem with ordered data mode. Begin: Running /scripts/local-bottom ... Done. Done. Begin: Running /scripts/init-bottom ... Done. Mount failed for selinuxfs on /selinux: No such device ^MINIT: version 2.86 booting^M Starting the hotplug events dispatcher: udevd. Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...agpgart: Detected an Intel 965G Chipset. and then hangs. -- Carlo Wood <[EMAIL PROTECTED]> - 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.22-rc5 regression
On Wed, Jun 20, 2007 at 09:15:21AM +0800, Wang Zhenyu wrote: > Yep, the device table patch doesn't change any function, so your problem > started from when 965G support patch has been in kernel. Yup > Carlo, pls try a kernel param of "pci=nommconf" to see if that could > fix your hang. There might be a BIOS bug, as similar issue also happen > like https://bugzilla.novell.com/show_bug.cgi?id=228683 That bugreport looks EXACTLY like the problem that I ran into. Note that they have the same motherboard as me: ASUS P5B Deluxe I will try pci=nommconf in a moment. It isn't the best workaround however as it should reduce the available RAM from 4GB to 3GB. agp=off would be a better workaround. Carlo Wood <[EMAIL PROTECTED]> - 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.22-rc5 regression
On Wed, Jun 20, 2007 at 03:11:20PM +0200, Carlo Wood wrote: > 2.6.22-rc5 BAD > 2.6.22-rc4+somethingelse BAD > 2.6.22-rc4+something GOOD > 2.6.22-rc4 BAD > ... > 2.6.18-rc1 BAD > 2.6.18 GOOD Ok, that made no sense. I meant: > 2.6.19-rc1 BAD > 2.6.18 GOOD -- Carlo Wood <[EMAIL PROTECTED]> - 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.22-rc5 regression
On Tue, Jun 19, 2007 at 05:09:10PM -0700, Linus Torvalds wrote: > Heh. > > Yeah, at this point I think we can pretty much guarantee that your problem > is one of two cases: > > - either a bit random, and depends on some timing thing, and one of the >kernels you marked "good" wasn't really. Nope >It's not likely that you marked a good kernel bad, of course, since >with a good kernel, everything should have always worked, but with a >bad kernel and a bug that isn't entirely reproducible, you'd mark it >"good" by mistake - because it just randomly didn't show the problem. Nope > OR > > - we actually have two different commits that introduce the problem for >you, and it comes and goes, and the bisection doesn't work, because >there isn't a clear "this side works, that other side does not" >situation. Yes Looking a bit closer to the bisect myself, I note that 25971f68d392f1816e21520e9e59648403b0bdad and aba297927d1d558c7a94548135133bdf9172708a are part of a branch that is derived from a very "old" revision. git bisect assumes that such an old revision is good, but in fact - that was already bad as well, because the history of this bug is: 2.6.22-rc5 BAD 2.6.22-rc4+somethingelse BAD 2.6.22-rc4+something GOOD 2.6.22-rc4 BAD ... 2.6.18-rc1 BAD 2.6.18 GOOD Thus: BAD BAD BAD GOOD GOOD BAD BAD and git bisect can't handle that, even though I started with a 'good' start point and a bad start point at the end. > For example, later on you say: > > > Personally I am convinced that the real problem is with > > 985144db8f4cb7e56154b31bdf233d3550bf > > but if you look at your commit log, you have: > > > # bad: [25971f68d392f1816e21520e9e59648403b0bdad] [PARISC] fix section > > # mismatch in ccio-dma > > git-bisect bad 25971f68d392f1816e21520e9e59648403b0bdad > > Notice? You said that 25971f68d392f1816e21520e9e59648403b0bdad was bad, > but that is *before_ the 985144db8f4cb7e56154b31bdf233d3550bf commit. > Do a > > gitk 25971f68d3..985144 > > to see that part of the history. This part is thus based upon a revision so old that it was bad again, even before the small period that it was good. > So maybe you didn't test that kernel properly? And maybe it really is > random, and something has happened that just makes it happen more often? No, it is really 100% reproducible. -- Carlo Wood <[EMAIL PROTECTED]> - 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.22-rc5 regression
On Mon, Jun 18, 2007 at 03:57:51PM -0700, Linus Torvalds wrote: > > I'll redo the bisect with this new git. > > Thanks, > Linus Well, I did a new 'git bisect' - and if you ask me - it is still broken. It's conclusion was this time: hikaru:/usr/src/kernel/git/linux-2.6>git bisect bad 01da41b86f6e5f9a724e20a63f093d77e37d8056 is first bad commit commit 01da41b86f6e5f9a724e20a63f093d77e37d8056 Author: Alexey Dobriyan <[EMAIL PROTECTED]> Date: Sat Mar 3 01:13:35 2007 + parisc: make command_line[] static Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]> :04 04 eb42c17f2b8c686380fa540723d09e4b27127236 0a77f9c56f35076ae79f9f12a37769500c8f5ee9 M arch Here is the log: hikaru:/usr/src/kernel/git/linux-2.6>git bisect log git-bisect start # bad: [188e1f81ba31af1b65a2f3611df4c670b092bbac] Linux 2.6.22-rc5 git-bisect bad 188e1f81ba31af1b65a2f3611df4c670b092bbac # good: [99f9f3d49cbc7d944476f6fde53a77ec789ab2aa] Merge branch # 'for-linus' of # git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband git-bisect good 99f9f3d49cbc7d944476f6fde53a77ec789ab2aa # good: [9808901b6c63a1c850b072e624c228901a9eaf10] Blackfin serial # driver: ignore framing and parity errors git-bisect good 9808901b6c63a1c850b072e624c228901a9eaf10 # bad: [aba297927d1d558c7a94548135133bdf9172708a] Merge # master.kernel.org:/pub/scm/linux/kernel/git/kyle/parisc-2.6 git-bisect bad aba297927d1d558c7a94548135133bdf9172708a # good: [0127d6d5d925321650e7b92364420325689a03ef] Merge branch 'master' # of master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6 git-bisect good 0127d6d5d925321650e7b92364420325689a03ef # bad: [25971f68d392f1816e21520e9e59648403b0bdad] [PARISC] fix section # mismatch in ccio-dma git-bisect bad 25971f68d392f1816e21520e9e59648403b0bdad # bad: [7022672e4046fac4699aa5f8ff2a5213b7ec4ff9] [PARISC] spelling # fixes: arch/parisc/ git-bisect bad 7022672e4046fac4699aa5f8ff2a5213b7ec4ff9 # bad: [fd3eef10f5a55acdefbd3f53ca7618a35cb6231f] [PARISC] Wire up # kexec_load syscall git-bisect bad fd3eef10f5a55acdefbd3f53ca7618a35cb6231f # bad: [2c8307f63dd5caaf7ff8ad5118951e559a9ed5c8] parisc: sync compat # getdents git-bisect bad 2c8307f63dd5caaf7ff8ad5118951e559a9ed5c8 # bad: [01da41b86f6e5f9a724e20a63f093d77e37d8056] parisc: make # command_line[] static git-bisect bad 01da41b86f6e5f9a724e20a63f093d77e37d8056 Personally I am convinced that the real problem is with 985144db8f4cb7e56154b31bdf233d3550bf [AGPGART] intel_agp: fix device probe This patch trys to fix device probe in two cases. First we should correctly detect device if integrated graphics device is not enabled or exists, like an add-in card is plugged. Second on some type of intel GMCH, it might have multiple graphic chip models, like 945GME case, so we should be sure the detect works through the whole table. Signed-off-by: Wang Zhenyu <[EMAIL PROTECTED]> Signed-off-by: Dave Jones <[EMAIL PROTECTED]> The result of this patch is that the kernel starts to print "agpgart: Detected an Intel 965G Chipset." again with the usual disastrous results. Now, that doesn't mean that this patch is wrong - but it explains why the problem returns after this patch. -- Carlo Wood <[EMAIL PROTECTED]> - 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.22-rc5 regression
On Mon, Jun 18, 2007 at 01:42:18PM -0700, Linus Torvalds wrote: > You really do want to use git-1.5.x these days. > > It does look like 1.4.4.4 may have a bug, although I'm really surprised: > we've certainly tweaked stuff in bisection, but I and others have used > "git bisect" since long before the git-1.4 days, and it has always worked > ok. So I wonder if it's something specific to that debian build. Well, it does indeed. Without changing ANYTHING to my linux-2.6 source tree - I just installed git 1.5.2.1 and now it behaves the way you describe. Conclusion: the weird behaviour that you think was wrong is totally due to git 1.4.4.4. I'll redo the bisect with this new git. -- Carlo Wood <[EMAIL PROTECTED]> - 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: GIT Packages for Debian Etch
On Mon, Jun 18, 2007 at 11:56:10PM +0200, Thomas Glanzmann wrote: > true. But when you run sid you get a newer version of git automatically. > Sooner or later. And you can always build it yourself. It's a pain in > the ass until you have all build dependencies installed and all the > tests pass. Oh, I already build it before my previous post :p I just did: sudo apt-get install libz-dev asciidoc xmlto libexpat1-dev subversion unzip tcl8.4 libsvn-perl libcurl3-dev after having a peek at git-core_1.5.2.1-1.dsc, and then it did build just fine immediately. -- Carlo Wood <[EMAIL PROTECTED]> - 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: GPLv3 dispute solution - new open source license?
I think that one of the main problems with the GPLv2 versus GPLv3 dispute is the discord that it saws between developers around the world. Right now, 66% is GPL, 6.5% is LGPL (using the stats from freshmeat here), 6% BSD, and the rest can be neglected ;) (see bottom of http://freshmeat.net/stats/) That means that if someone decides that he wants to write free software (and license it under the GPL), he can choose from a large code base. What those stats don't say, however - is how many people said "version 2 or later", and how many said "version 2". If next people start to write software - they might be forced to use GPLv2 because they want to use other software that was only version 2. While others will start to write new software under version 3 (if only because they don't know better - like 90% of the people who copied the template with "version 2 or later"). The result is that two seperate groups of software will start to emerge that cannot use from eachother. And because both will be consirably large, that is a Bad Thing(tm). Imho, it is much worse that this seperation of the pool of open source code will occur than everyone using version 2, or everyone using version 3, and the effect that that will have. Now, writing yet another license for the linux kernel is therefore NOT the solution - if you get my drift. -- Carlo Wood <[EMAIL PROTECTED]> - 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: GIT Packages for Debian Etch
On Mon, Jun 18, 2007 at 10:27:41PM +0100, Pierre Habouzit wrote: > FWIW there is even simpler: I maintain a backport on > www.backports.org. Which is a semi-official service driven by Debian > Developers. It seems that this is only for etch (and sarge). I run a mixed Lenny/sid machine here. It doesn't necessarily work when I start to install things for etch. Certainly not once testing upgrades its libc. Or? -- Carlo Wood <[EMAIL PROTECTED]> - 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: [AGPGART] intel_agp: use table for device probe
On Mon, Jun 18, 2007 at 10:37:26AM +0800, Wang Zhenyu wrote: > Carlo, I've just built latest kernel git tree on a Dell 965G box and > have a NV card plugged-in. It boots fine. It would be nice if you could test it with the exact same hardware ... I am pretty sure it should be reproducable then *cough* > Linux agpgart interface v0.102 (c) Dave Jones > agpgart: Detected an Intel 965G Chipset. > agpgart: AGP aperture is 256M @ 0x0 > > I don't know why it hangs your machine when loading this module, it should > just not bother anything. But from your last "modprobe: ..." line, it seems > there's really badness somewhere, do you have serial console to see more > in the message? The reason I react a bit late to your post is because in the meantime I set up a serial console and figured out how to boot that way... and captured the boot messages. I will add that to one of the other posts, because as a result of what they posted there I added agp=off - and that (indeed) makes it possible for me to boot. Please see my next post thus. -- Carlo Wood <[EMAIL PROTECTED]> - 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.22-rc5 regression
On Mon, Jun 18, 2007 at 11:35:03AM -0700, Linus Torvalds wrote: > I can follow along, but I get *totally*different* git bisection points! > > > hikaru:/usr/src/kernel/git/linux-2.6>git bisect start > > hikaru:/usr/src/kernel/git/linux-2.6>git bisect bad v2.6.22-rc5 > > hikaru:/usr/src/kernel/git/linux-2.6>git bisect good > > 99f9f3d49cbc7d944476f6fde53a77ec789ab2aa > > Bisecting: 128 revisions left to test after this > > D include/asm-blackfin/macros.h > > M scripts/package/Makefile > > D scripts/package/builddeb > > You seem to have a modified tree! What are those modifications to the > blackfin macros.h etc files? I never (manually) changed anything - so, this should be the result of the fact that I use the same directory tree to (re)build the kernel every time. That 'D' means they are deleted I'd think - so the changes are clear. I am sorry, but I am totally new to git - I know cvs and svn (and even then I never used branches :(), but I don't know how to find out what those differences are with git. I could start looking on the web - but it's a fact that I don't even know what I would look for: in order to create a diff one needs two points. No doubt one point is the current state of my local copy, but what would that other point be to compare with? If you would be so kind to ask things like: What is the result of this or that command, when it comes to git, then I will be faster and more accurate to tell you :). I added the result of 'git diff' below. > You *should* have gotten this: > > [EMAIL PROTECTED] linux]$ git bisect start > [EMAIL PROTECTED] linux]$ git bisect bad v2.6.22-rc5 > [EMAIL PROTECTED] linux]$ git bisect good > 99f9f3d49cbc7d944476f6fde53a77ec789ab2aa > Bisecting: 127 revisions left to test after this > [9808901b6c63a1c850b072e624c228901a9eaf10] Blackfin serial driver: > ignore framing and parity errors > > but those are just off by one, at least (127 vs 128 commits left). > > > [cf68676222e54cd0a31efd968da00e65f9a0963f] Blackfin serial driver: actually > > implement the break_ctl() function > > hikaru:/usr/src/kernel/git/linux-2.6>git bisect good > > Bisecting: 111 revisions left to test after this > > And that's totally broken. Even if I don't use the "9808901b6" commit, and > use your "cf686762" commit, I get: > > [EMAIL PROTECTED] linux]$ git bisect good > cf68676222e54cd0a31efd968da00e65f9a0963f > Bisecting: 63 revisions left to test after this > [aba297927d1d558c7a94548135133bdf9172708a] Merge > master.kernel.org:/pub/scm/linux/kernel/git/kyle/parisc-2.6 > > Notice? The "127 revisions left to test after this" has become "63 > revisions left to test after this". Well,... when, and because, it's not a linear thing as you mentioned before - it's not necessarily precisely a cut into half... so I thought, seeing those weird (not half) numbers that that was the cause. > That number should be cut in half each time. And you shouldn't get some > strange dirty tree indications. > > It might be worth it just making sure your git is ok. It really is acting > oddly. What version is it? git version 1.4.4.4 I am using Debian (suite 'testing') and trying to be a debian purist - so it isn't like I can easily upgrade to 1.5.x : there is no debian package for that version in 'testing'. Nevertheless, if you think it's important - then I can download and compile a tar ball of course - certainly when I don't have to install it to test it. -- Carlo Wood <[EMAIL PROTECTED]> PS The result of 'git diff' is: diff --git a/include/asm-blackfin/macros.h b/include/asm-blackfin/macros.h deleted file mode 100644 index e69de29..000 diff --git a/scripts/package/Makefile b/scripts/package/Makefile index 7c434e0..f758b75 100644 --- a/scripts/package/Makefile +++ b/scripts/package/Makefile @@ -1,99 +1,2 @@ -# Makefile for the different targets used to generate full packages of a kernel -# It uses the generic clean infrastructure of kbuild - -# Ignore the following files/directories during tar operation -TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn --exclude CVS - - -# RPM target -# --- -# The rpm target generates two rpm files: -# /usr/src/packages/SRPMS/kernel-2.6.7rc2-1.src.rpm -# /usr/src/packages/RPMS/i386/kernel-2.6.7rc2-1..rpm -# The src.rpm files includes all source for the kernel being built -# The .rpm includes kernel configuration, modules etc. -# -# Process to create the rpm files -# a) clean the kernel -# b) Generate .spec file -# c) Build a tar ball, using symlink to make ke
Re: 2.6.22-rc5 regression
On Mon, Jun 18, 2007 at 08:12:25PM +0200, Carlo Wood wrote: > ones that boot correctly always booted correctly, while the ones that > hung, always hung (although in a totally reproducable way). Sorry - that should be "although NOT in a totally reproducable way" If you every doubt it's the Real Carlo Wood, look for him leaving out the word 'not' 50% of the time ;) -- Carlo Wood <[EMAIL PROTECTED]> - 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.22-rc5 regression
On Mon, Jun 18, 2007 at 10:01:34AM -0700, Linus Torvalds wrote: > On Sun, 17 Jun 2007, Carlo Wood wrote: > > > > If you want my opinion on this: git bisect is broken :p > > I was very surprised that it printed this at this point. > > Hmm. Possible. However, I *really* would need the git bisect log to see > what's up. I had already done a git bisect reset :/ > So far, we have never seen a bug in "git bisect" that wasn't > either due to the user specifying path-names to limit the testing (and the > bug not being in that set of path-names), or the user not realizing that > with non-linear history the "git bisect" is actually a fairly complex op. I realize that it is non-linear - and I didn't do anything to "speed things up". Just build -> boot -> git bisect good/bad -> build etc. > That said, "git bisect" _can_ give the "wrong" results in the sense that > the commit it points to may not be the one you are actually looking for, > if: > > - the bug is sporadic, and not entirely repeatable, and a kernel you >marked as good wasn't really good, your test just didn't happen to >catch it that time around. > > - the bug comes and goes, and the commit that "git bisect" pinpoints may >well *show* the bug, but may not be the *cause* of the bug (ie there >might be two or more independent things that have to come together for >the bug to trigger, and as a result there is not a "single" commit that >acts as a clear boundary) I don't believe that either of these is the case. I have booted about 8 different kernel revisions several times (most three times), alternating between them (not the same three times on a row) and the ones that boot correctly always booted correctly, while the ones that hung, always hung (although in a totally reproducable way). Nevertheless, it is not 100% impossible. I have the feeling that it MIGHT be related to the fact that I have 4 CPU's - and that perhaps some race condition is involved. And if that is the case, then there might be some kernel version where boot/not-boot is less reliable then with the eight I tested - apart from that three times isn't very much (but doing it for four good kernels and two bad kernels, it still is a reasonable indication for reproducability). > But hey, a bug in "git bisect" is certainly _possible_. I just consider it > fairly unlikely by now. > > One bisect before, it said there were still 96 revision to check. > > > > Anyway - here are some facts of the kernels that I tested: > > You seem to not actually have used "git bisect" to generate this list. I didn't -- what is the command to generate a list like this with git? > Quite frankly, the most likely cause for the bad bisection result is that > you have not used "git bisect" at all to let it pick the bisection points. Heh - now you are insulting me :p I said I did, and I did. The reason that I made that list manually is because wanted to have more overview. I use this alias to build the kernels: hikaru:/usr/src/kernel/git/linux-2.6>alias build alias build='cp /boot/config-2.6.22-rc4-hikaru-amd64 .config && make-kpkg clean && VER=$(date +"%Y%m%d%H%M") && BRANCH=$(git branch | grep "^\*" | sed -e "s/\* //") && NAMEEXT="-$BRANCH-$(git rev-list --max-count=1 $BRANCH)-$(dpkg-architecture -qDEB_HOST_ARCH)" && make-kpkg --revision=$VER --append-to-version=-$NAMEEXT --rootcmd fakeroot clean && make-kpkg --revision=$VER --append-to-version=$NAMEEXT --rootcmd fakeroot --initrd kernel_image modules_image' That results in debian kernel package names like: -rw-r--r-- 1 carlo carlo 18790180 2007-06-17 22:55 linux-image-2.6.22-rc4-bisect-d09c6b809432668371b5de9102f4f9aa6a7c79cc-amd64_200706172247_amd64.deb -rw-r--r-- 1 carlo carlo 18790446 2007-06-17 22:42 linux-image-2.6.22-rc4-bisect-ce9b2b0abbf019d5259eb089a1cc256852930f67-amd64_200706172234_amd64.deb -rw-r--r-- 1 carlo carlo 18789884 2007-06-17 22:24 linux-image-2.6.22-rc4-bisect-d1be0a8225f2cb1cdc356ebb0ae6800f023ce67d-amd64_200706172216_amd64.deb -rw-r--r-- 1 carlo carlo 18790420 2007-06-17 22:09 linux-image-2.6.22-rc4-bisect-de7f928ca460005086a8296be07c217aac4b625d-amd64_200706172201_amd64.deb -rw-r--r-- 1 carlo carlo 18790430 2007-06-17 21:04 linux-image-2.6.22-rc4-bisect-3e903e7b1605aff88d7f89a96fab5e43081b914f-amd64_200706172032_amd64.deb -rw-r--r-- 1 carlo carlo 18789698 2007-06-17 20:21 linux-image-2.6.22-rc4-bisect-cf68676222e54cd0a31efd968da00e65f9a0963f-amd64_200706172012_amd64.deb -rw-r--r-- 1 carlo carlo 18789796 2007-06-17 18:51 linux-image-2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64_20070617
Re: [AGPGART] intel_agp: use table for device probe
On Mon, Jun 18, 2007 at 12:18:32PM +1000, Dave Airlie wrote: > Well it was more for davej's benefit, in theory for your machine with > a PCIE graphics card you don't need agpgart enabled at all granted it > shouldn't screw up if it is.. I can't disable it though. I am not THAT much interested in disabling it however as long as I get help here to debug this. I am interested in finding out what is causing the crash, can't stand it to have a bug on my machine without knowing what it is ;) -- Carlo Wood <[EMAIL PROTECTED]> - 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: [AGPGART] intel_agp: use table for device probe
On Mon, Jun 18, 2007 at 10:57:38AM +1000, Dave Airlie wrote: > >Right now, I'm at a loss to explain the corruption, so it's > >difficult to suggest what to try. > > The thing is here, this is PCIE, so if there is a GPU plugged into the > PCIE 16x slot in theory the main onboard graphics should disable, AGP > code is used to control the GART for the onboard chip, in this case a > plugged in card will not use AGP, I wonder have Intel tested with a > pcie card in place... That is Chinese for me :/. Do you want me to try something? -- Carlo Wood <[EMAIL PROTECTED]> - 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.22-rc5 regression
On Mon, Jun 18, 2007 at 08:18:58AM +0900, Paul Mundt wrote: > The obvious question of course is whether actually reverting this > changeset fixes your problem? I would be very surprised if it did. Having a git commit Id, like d09c6b809432668371b5de9102f4f9aa6a7c79cc, how can I create a .diff file from that? > If it does make a difference, please provide the values for > CONFIG_HOTPLUG, CONFIG_MEMORY_HOTPLUG and CONFIG_HOTPLUG_CPU from your > .config. > > I would wager that you only have CONFIG_HOTPLUG=y, in which case, the > only difference over previous kernels will be that zone_batchlist() is no > longer flagged as __init, and so it won't be freed -- this was the reason > for the "special section" comment in the changeset, as currently it's > left hanging around for folks that aren't doing cpu/memory hotplug, since > __devinit was the closest that both cpu and memory hotplug had in common. > > I can't imagine that this would impact you at all, though. I think git bisect made an error... as you can see for yourself with the list of tested git Id's that I gave - it didn't test both sides of that patch imho. If you tell me how to extract a patch then I'll manually unapply it to some failing kernel revisions and see if that makes a difference. -- Carlo Wood <[EMAIL PROTECTED]> - 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: [AGPGART] intel_agp: use table for device probe
On Sun, Jun 17, 2007 at 06:49:18PM -0400, Dave Jones wrote: > ok, then you must have CONFIG_AGP=y I do - not voluntary however. For some mysterious reason I am unable to set it to n or m. I am also not able to set CONFIG_AGP_INTEL to n, only to y or m. (using make 'menuconfig' for example). > > $ find /lib/modules -name 'agpgart.ko' > > $ > /lib/modules/2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64 > -name '*agp*.ko' > > > /lib/modules/2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64/kernel/drivers/char/agp/sis-agp.ko > > > /lib/modules/2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64/kernel/drivers/char/agp/intel-agp.ko > > > /lib/modules/2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64/kernel/drivers/char/agp/via-agp.ko > > > > 2) > > > > $ strings > /lib/modules/2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64/kernel/drivers/char/agp/intel-agp.ko > | grep 'agpgart: Detected an Intel' > > <6>agpgart: Detected an Intel %s Chipset. > > > > Hence, in the case that the kernel works, intel-agp is loaded > > WITHOUT printing this Detected line > > That doesn't make much sense. The hardware doesn't change between > a working & not-working kernel, and somehow the PCI probing fails. > Hmm, do you have CONFIG_EDAC set ? CONFIG_EDAC=m $ lsmod | grep edac $ > There's an outstanding bug (well, lack of feature) , where it claims > the PCI device before AGP gets a chance to. > This is unrelated to your hang however, but would at least explain > the inconsistent probing. > > > Perhaps my "solution" is to remove this module completely? > > I don't seem to need it. > > It's needed only for 3d, Nope - I just played UT2004 without problems, and without intel-agp loaded. > but it'd be good to figure out why its so > broken on your system, even if you don't need it. Please tell me what to do / try. I'm an experienced coder - but I never really played with the kernel before - so you'll have to spell out how to turn on debugging etc. -- Carlo Wood <[EMAIL PROTECTED]> - 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: [AGPGART] intel_agp: use table for device probe
On Sun, Jun 17, 2007 at 05:33:55PM -0400, Dave Jones wrote: > intel-agp > > Though by the looks of things, with the working kernel, you don't have > it loaded (it's dependant upon the 'agpgart' module, which prints the > "Detected" line that was missing). You are wrong. 1) I don't have any agpgart module at all, in any of the kernels that I compiled. $ find /lib/modules -name 'agpgart.ko' $ /lib/modules/2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64 -name '*agp*.ko' /lib/modules/2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64/kernel/drivers/char/agp/sis-agp.ko /lib/modules/2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64/kernel/drivers/char/agp/intel-agp.ko /lib/modules/2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64/kernel/drivers/char/agp/via-agp.ko 2) $ strings /lib/modules/2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64/kernel/drivers/char/agp/intel-agp.ko | grep 'agpgart: Detected an Intel' <6>agpgart: Detected an Intel %s Chipset. Hence, in the case that the kernel works, intel-agp is loaded WITHOUT printing this Detected line - while when it doesn't work, it is loaded while printing this line. Perhaps my "solution" is to remove this module completely? I don't seem to need it. -- Carlo Wood <[EMAIL PROTECTED]> - 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: [AGPGART] intel_agp: use table for device probe
On Sun, Jun 17, 2007 at 05:33:55PM -0400, Dave Jones wrote: > > What would the name be of such module? > > intel-agp > > Though by the looks of things, with the working kernel, you don't have > it loaded (it's dependant upon the 'agpgart' module, which prints the > "Detected" line that was missing). I can rmmod intel-agp without problems. The agpgart module isn't loaded. -- Carlo Wood <[EMAIL PROTECTED]> - 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: [AGPGART] intel_agp: use table for device probe
On Sun, Jun 17, 2007 at 05:33:55PM -0400, Dave Jones wrote: > > What would the name be of such module? > > intel-agp > > Though by the looks of things, with the working kernel, you don't have > it loaded (it's dependant upon the 'agpgart' module, which prints the > "Detected" line that was missing). hikaru:~>lsmod | grep agp intel_agp 31776 0 It's loaded right now... that is with 2.6.22-rc4-+something (one of the working ones). I don't know WHEN it was loaded though. Probably not at the same time as the others. And hikaru:~>dmesg | grep agpgart Linux agpgart interface v0.102 (c) Dave Jones No 'Detected' line :/ Also, I noted that this 'agpgart: Detected..' line is always(?) printed right after (often even without THAT line having printed a newline yet!) something like: udev: Waiting for /dev to be fully populated...agpgart: Detected an Intel 965G Chipset. And this 'udev: Waiting for /dev to be fully populated' (sorry, didn't write down the exact phrase, this is from memory) is also not printed by kernels that work. -- Carlo Wood <[EMAIL PROTECTED]> PS I asked you move to the other thread - it's a bit annoying to have two threads about this now. - 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.22-rc5 regression
v2.6.19-rc1 GOOD v2.6.18 The order and date is the order and date as is shown by gitk --all. I'd appreciate any suggestions or questions at this point, as I have no idea what to do next to find this problem. -- Carlo Wood <[EMAIL PROTECTED]> PS The hardware that I'm using is: An ASUS P5B Deluxe motherboard with an Intel Core 2 Quad QX6700 2.66 GHz, 4 GB of low latency DIMMs (two times KHX6400D2LLK2/2GN - two DIMM's each, 4 DIMM's in total, which are CL4-4-4). Asus EN8600 GTS 256MB. - 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: [AGPGART] intel_agp: use table for device probe
On Sun, Jun 17, 2007 at 04:49:04PM -0400, Dave Jones wrote: > That's pretty bad corruption indeed. What I'm puzzling over though > is why other 965G users aren't seeing the same thing. > My own 965G seems to be fine, though that's using Intel graphics > instead of nvidia. > > (Just to rule it out, I'm assuming at this stage in boot that the > nvidia driver module has never been loaded?) Doesn't even exist for that kernel. I only compiled a new nvidia driver module for one kernel - the one that I am using on a daily basis. > And if you never load the agpgart modules, you never see lockups? What would the name be of such module? In fact, I think that when the kernel does NOT lockup, it doesn't print this "agpgart: Detected.." line either. Ie, the dmesg of cf68676222e54cd0a31efd968da00e65f9a0963f which boots fine, gives: $ grep Detected dmesg-cf686 time.c: Detected 2666.669 MHz processor. Detected 16.666 MHz APIC timer. $ grep agpgart dmesg-cf686 Linux agpgart interface v0.102 (c) Dave Jones Does that give an indication of what you want me to test/try? -- Carlo Wood <[EMAIL PROTECTED]> - 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: [AGPGART] intel_agp: use table for device probe
On Sun, Jun 17, 2007 at 03:07:14PM -0400, Dave Jones wrote: > Sometimes things fall through the cracks.. > I haven't heard any similar problems, which makes it somewhat odd. Ok. Well, the lockup is all to real here :p I suspect a memory corruption going on, as under certain circumstances there is printed more after the "agpgart: Detected an Intel 965G Chipset." -- that is, the kernel *sometimes* doesn't hang silently, but either reboots by itself (hard reset) or prints something that looks like a total crash to me. Often, this is prefixed by the name of running process. I am sorry, I never wrote any of that down. Only the last time, it then went like: agpgart: Detected an Intel 965G Chipset. modprobe: Corrupt page table at address 20 PGD 178c6c067 PUD 201000c0049c04f BAD This very same kernel (I boot it several times to see how reproducable things were) always prints "agpgart: Detected an Intel 965G Chipset." but then either hangs (two times), prints the above and hangs (one time) or hard resets (one time). Then I also booted the other kernels several times, and kernels that booted fine ALWAYS boot fine - while kernels that locked up (that I tested by booting them three times) only printed the agpgart line and locked up three times. > > The patch causes my machine to lock up and/or crash > > in various ways (depending on the exact version of the kernel), > > very shortly after printing: agpgart: Detected an Intel 965G Chipset. > > > > The first kernel version that stops doing that is 2.6.22-rc5. > > I used git bisect once more to find the patch that fixes this bug: > > I am mailing this mostly because the comment doesn't seem to indicate > > that the author is aware that this patch fixes an existing regression > > (it worked fine for me with 2.6.18). > > Indeed, it was unknown to me too, this should have just been > a clean-up. I hope you saw my later post too? I sent it to you too - but also to the list, so I don't know if you'll notice it. The Subject of that post is: 2.6.22-rc5 regression I concluded too soon that 2.6.22-rc5 was working :(. I just really tested it and it doesn't! Same error. Please have a look at that other post of me and lets continue this thread there. > Out of curiousity, I'd like to see your lspci > (not -v or anything, just run with no args) I'll add that to that other thread. -- Carlo Wood <[EMAIL PROTECTED]> - 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.22-rc5 regression
On Sun, Jun 17, 2007 at 03:07:14PM -0400, Dave Jones wrote: > Out of curiousity, I'd like to see your lspci > (not -v or anything, just run with no args) $ lspci 00:00.0 Host bridge: Intel Corporation P965/G965 Memory Controller Hub (rev 02) 00:01.0 PCI bridge: Intel Corporation P965/G965 PCI Express Root Port (rev 02) 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #4 (rev 02) 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #5 (rev 02) 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #2 (rev 02) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02) 00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #3 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #1 (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2) 00:1f.0 ISA bridge: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801HB (ICH8) SATA AHCI Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation Unknown device 0400 (rev a1) 02:00.0 Ethernet controller: Marvell Technology Group Ltd. Unknown device 4364 (rev 12) 04:02.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 08) 04:02.1 Input device controller: Creative Labs SB Live! Game Port (rev 08) 04:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) -- Carlo Wood <[EMAIL PROTECTED]> - 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: How to improve the quality of the kernel?
On Sun, Jun 17, 2007 at 09:18:17PM +0200, Rafael J. Wysocki wrote: > where n is a number that needs to be determined (I think that n could be 3). > Well, "negative comments" should also be defined more precisely. ;-) I think that n should be a function of the number of accepted patches that this person sent in before, and the number of regressions he caused in the past. Ie, new developers have to wait a considerable amount of time - while experienced developers who never caused a regression should be able to write patches that are immediately applied. Also, if anyone causes a regression - that would lead to them having to wait longer the next time before they can apply the patch - a good reason for a developer to put extra time into making sure there are no regressions. -- Carlo Wood <[EMAIL PROTECTED]> - 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/
2.6.22-rc5 regression
I cheered too soon ... I just tested 2.6.22-rc5 and it hangs again at the same point, right after printing: agpgart: Detected an Intel 965G Chipset. So far I tested: 188e1f81ba31af1b65a2f3611df4c670b092bbacBAD 2007-06-17 04:09:12 v2.6.22-rc5 99f9f3d49cbc7d944476f6fde53a77ec789ab2aaGOOD2007-06-12 00:46:08 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband 3334500b460a5eede2e3466ca97a90fe3b91ceb5GOOD2007-06-11 20:39:05 Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/agpgart df80b148869291621ddf51eb8716658d5bfba811GOOD2007-05-31 05:51:21 [AGPGART] intel_agp: add support for 945GME 9614ece14f23f2ce54a076c471aec9c91e51e79cGOOD2007-05-30 03:45:58 [AGPGART] intel_agp: use table for device probe c4ca881796b7e14120851ddf6e04845ef94a314aBAD 2007-05-30 03:40:46 [AGPGART] intel_agp: cleanup intel private data e141d999b682cda9907179e3b843acb64c34a1d8BAD 2007-06-10 07:26:20 b44c0267b7571b449e05f390349c4e4d080f0f4cBAD 2007-06-11 20:32:28 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb bb3d2dd72302ea3eefcc6738cdd39ed5864b62f8BAD 2007-06-11 20:31:43 Merge master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6 1a539a87280b3032fd12bc93a4a82f1d8aa97ca8BAD 2007-06-08 22:46:58 5ecd3100e695228ac5e0ce0e325e252c0f11806fBAD 2007-06-05 02:57:25 v2.6.22-rc4 c420bc9f09a0926b708c3edb27eacba434a4f4baBAD 2007-05-26 04:55:14 v2.6.22-rc3 55b637c6a003a8c4850b41a2c2fd6942d8a7f530BAD 2007-05-19 06:06:17 v2.6.22-rc2 ... ... BAD v2.6.19-rc1 GOOD v2.6.18 I am now doing a bisect between 99f9f3d49cbc7d944476f6fde53a77ec789ab2aa and 188e1f81ba31af1b65a2f3611df4c670b092bbac. The hardware that I'm using is: An ASUS P5B Deluxe motherboard with an Intel Core 2 Quad QX6700 2.66 GHz, 4 GB of low latency DIMMs (two times KHX6400D2LLK2/2GN - two DIMM's each, 4 DIMM's in total, which are CL4-4-4). Asus EN8600 GTS 256MB. -- Carlo Wood <[EMAIL PROTECTED]> - 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/
[AGPGART] intel_agp: use table for device probe
On Thu, Jun 14, 2007 at 03:15:06AM +0200, Carlo Wood wrote: > Hi Dave, I have an amd64 box for which every kernel > after 2.6.18 hangs during boot, so I have no dmesg :( > > I used git bisect to find out where the problem patch is, > and assuming bisect works (imho it jumped between versions > very weirdly: closing in on the last 6 revisions, it > jumped from 2.6.18 to 2.6.18-rc2 to 2.6.18-rc6), the problem > is a patch in intel-agp.c, where support for the intel 965G > is added (which I have). > > I mailed the author of the patch, including the git Id > of that patch... but he didn't reply... and I didn't keep the > mail :/ So, I am afraid I can't give much details. > > I'd still like to have it sorted out. If you give me the > green light (in the sense that you are willing to help > a kernel-newbie when needed) then I'll have another > attempt at getting more information. Dave, I have no idea why you never replied to this -- don't you care that kernels 2.6.19 through 2.6.21 lockup on boot? -- here is a follow up on this matter. I am not sure which patch it was exactly that broke things, but I think it was: [AGPGART] Intel 965 Express support. From: Alan Hourihane <[EMAIL PROTECTED]> From: Eric Anholt <[EMAIL PROTECTED]> Signed-off-by: Dave Jones <[EMAIL PROTECTED]> 65c25aadfa4e917060e99fe459f33a6a07db53cc which was supplied after 2.6.18 and before 2.6.19-rc1. If I remember that correctly, then Alan should have a mail from me with the exact git Id (he never replied either). The patch causes my machine to lock up and/or crash in various ways (depending on the exact version of the kernel), very shortly after printing: agpgart: Detected an Intel 965G Chipset. The first kernel version that stops doing that is 2.6.22-rc5. I used git bisect once more to find the patch that fixes this bug: commit 9614ece14f23f2ce54a076c471aec9c91e51e79c Author: Wang Zhenyu <[EMAIL PROTECTED]> Date: Wed May 30 09:45:58 2007 +0800 [AGPGART] intel_agp: use table for device probe Fixed issues noted by Christoph Hellwig, and I changed device table scan a bit to allow the case that some models of graphics chips may have same host bridge type. This type of chip will be added in the future. This patch cleans up device probe function. Eric Anholt was the original aut hor. Signed-off-by: Eric Anholt <[EMAIL PROTECTED]> Signed-off-by: Wang Zhenyu <[EMAIL PROTECTED]> Signed-off-by: Dave Jones <[EMAIL PROTECTED]> :04 04 625da154215c98f9016e14b952131a0c1ec8597b cddcf0b42d3632d20d7ee863 91d6ae6d258632e2 M drivers I am mailing this mostly because the comment doesn't seem to indicate that the author is aware that this patch fixes an existing regression (it worked fine for me with 2.6.18). Anyway, thanks for fixing this Wang Zhenyu. If anyone wants to know more (like what hardware I'm using), please show me that you're actually alive / reading my mails. -- Carlo Wood <[EMAIL PROTECTED]> - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sat, Jun 16, 2007 at 08:21:22PM -0600, Jeffrey V. Merkey wrote: > Linus, > > Just take a vote and start tagging files and ignore this needless > diatribe. It is was it is, I seriously doubt you will > get all of Linux moved to GPL3 as a monolith, since you will never get > concensus. You should fork a GPL3 kernel and let people decide > whether their code goes in or not. If they don't want to move to it, new > people can contribute new code. Start a 2.8 tree or whatever that is > GPL3 only. *snicker* Yeah, Linus - when do you finally understand that nobody WANTS your GPL3 kernel? :)) ROFL -- Carlo Wood <[EMAIL PROTECTED]> - 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: My kernel hangs again: Help with git please
On Sat, Jun 16, 2007 at 01:28:13AM -0400, Daniel Barkalow wrote: > That's not actually the right image. There's a graph of commits with a lot > of splitting and joining lines. Each branch and each tag sits something in > this web. The difference between branches and tags is that you're expected > to move branch pointers around, and tags stay mostly in place. There's no > accounting of commits newer than the current spot in the web for a branch > belonging to that branch, so if you move a branch back to an older tag (or > other commit), the spot it's leaving is no longer "on the branch". Okay, it took me two hours before I understood this... but here's the picture that I have in mind now: master->X(merge point) /| / | ^ branch->3 X Time | | | | 2 X | | 1 X | | \ | \| X(branch point) | Then if I define a branch pointer to point to '3', then the branch is 3--2--1. If next I move the branch pointer to point to '2', node '3' is no longer on the branch because now the branch exists of 2--1, and HEAD moves to '2' as well. This seems to make most sense in the light of your last sentence. I don't understand how I'd have moved branch pointers however. I thought I would just change my working copy along the branch by specifying tag nodes. Ie, I have a branch '3'(--2--1) and I say: give me '2', then give me '1' - and when I do: git reset --hard HEAD - it moves me to 3 because the branch was never touched. > So master is a point in the web, and bisect jumps around through the web > according to some special rules (due to having git-bisect use the good/bad > marks do determine which commit to try next, and jump there). git-bisect > doesn't really even care that you started on any single branch. It's just > operating on the web, and the branch you start on is treated as an > arbitrary commit that has the problem. Ok - so it does something magical that I don't have to understand :P The only thing that matters is that I choose the begin and end point, the first two points, correctly: where one is bad and the other is good. I seems that git bisect can't deal with swapping good/bad (the 'bad' one always has to be the newest revision), so I had decided to call 'kernel hangs' good and 'kernel works' bad. The problem then is that I can't find any starting point anymore that is 'bad'. > You may find "gitk --all" informative. The dates on the right side seem to make no sense. Even in a part where there are no branches/merges at all, the date goes in both direction (sometimes older, sometimes newer). Roughly it seems that the newest date is at the top - but I see a lot of times things like: |||O|| Description Author1 2007-05-14 03:43:20 |||O|| Description Author2 2007-05-15 15:10:34 |||O|| Description Author3 2007-05-13 17:50:27 Thus, there seems to be no time related ordering :/ > It looks like you moved master back to 2.6.22-rc4 (with git reset --hard > v2.6.22-rc4) at some point. Yup, I can see that in the gitk --all graph :) > What you should do now is: > > $ git checkout master > $ git merge origin > > Which should move master forward through the web to "origin", which is > (unless you've moved it) what you got from upsteam. $ git merge origin fatal: Needed a single revision Usage: /usr/bin/git-merge [-n] [--no-commit] [--squash] [-s ]... + For some reason I don't think I should be needing commands that need ""; I don't want to change the (local) tree in anyway. Isn't there another way to just move master back to the HEAD of origin? > Alternatively: > > $ git checkout master > $ git pull > > Should fetch the latest stuff and advance master to the fetched version. I'd rather first reproduce a working kernel - that should be possible without pulling in more commits. -- Carlo Wood <[EMAIL PROTECTED]> - 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: My kernel hangs again: Help with git please
On Fri, Jun 15, 2007 at 08:33:38PM -0400, Daniel Barkalow wrote: > HEAD doesn't mean what you think it means. It's the latest revision on the > branch with the *. What you want is: > > $ git checkout master > > This will move the * to "master", which shouldn't have been affected by > any of this, and move your working directory to this point as well. At > that point, you should be able to build a working kernel. > > What "git reset --hard HEAD" does is discard any differences to tracked > files between your working directory and the revision you're on. It's > relevant if you want to discard local changes, not otherwise. I don't understand - any branch that I am on has many tags. I can use 'git reset --hard sometag' to change the source tree to that tag (which works if I look at the version in the Makefile and pick tags that are far apart enough). Then, shouldn't 'HEAD' have the meaning: the newest tag on the branch? I was on the 'bisect' branch - but that is a copy of the master, no? At least, that was what I started on when I started the bisect. Anyway, I tried this: $ git checkout master $ git branch bisect * master origin $ BRANCH=$(git branch | grep "^\*" | sed -e "s/\* //") $ echo $BRANCH master $ git rev-list --max-count=1 $BRANCH 5ecd3100e695228ac5e0ce0e325e252c0f11806f Is it correct that this last command gives me the 'git id' (if that is the correct name for the hash) of the revision that my local working copy is at? Can you tell me what is the latest git id that you see? Because, if I compile 5ecd3100e695228ac5e0ce0e325e252c0f11806f is still hangs at boot :( I really don't know how I got a working kernel before :/ -- Carlo Wood <[EMAIL PROTECTED]> - 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/
My kernel hangs again: Help with git please
Somewhere between 2.6.18 and 2.6.19, a patch was added to the kernel that makes it hang on my machine after the message: apgart: Detected an Intel 965G Chipset. When I upgraded to 2.6.22-rc4 (from debian trunk), I still ran into this same bug. After installing git for the first time, I made my first little steps with git - but it didn't get any further then an attempt to mount my root because I had done my configuration wrong (due the fact that libata seems to have moved). Later, I managed to get the configuration right, compiled HEAD (I think) and got a working 2.6.22-rc4 (+ patches). I was very happy, and assumed that by coincidence the very bug that was introduced shortly after 2.6.18 that made my machine hang during boot, was fixed only two or so days after I joined linux-kernel and installed git, somewhere after 2.6.22-rc4 ... What a coincidence right? Indeed, I thought it was a bit TOO much of a coincidence. So I just HAD to see that patch that fixed the problem, and I tried to used git bisect to find the patch that changes the behaviour from a hang to a working kernel (that I am now using to write this very mail). Surprise: Nothing I try produces a working kernel anymore?! Therefore I have the following questions: 1) What git command will ASSURE that I get the LATEST kernel tree checked out? I tried this: hikaru:/usr/src/kernel/git/linux-2.6>git branch -l * bisect master origin hikaru:/usr/src/kernel/git/linux-2.6>git reset --hard HEAD hikaru:/usr/src/kernel/git/linux-2.6>git rev-list --max-count=1 bisect c420bc9f09a0926b708c3edb27eacba434a4f4ba And, assuming I have c420bc9f09a0926b708c3edb27eacba434a4f4ba at that moment, then git reset --hard HEAD didn't do what I wanted: that is namely -rc3 even! I can see THAT in the Makefile -- but whenever I see -rc4 in the Makefile, that doesn't garantee in any way (apparently) that I have the latest of the latest. 2) Is there some way to find back the exact version (git id) from the .config, System.map and vmlinuz image (or /proc, since I can boot it)? Because that is all I have left from the time that I managed to create a working kernel :( -- Carlo Wood <[EMAIL PROTECTED]> - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
This was actually a part of a larger reply - but I decided not to sent that. Didn't want to throw away the work I did to get accurate numbers though ;) I investigated: find -name "*.c" | wc --lines 11100 find -name "*.c" | xargs egrep "(version 2.*([Ll]icense|redistribute|released|GNU|GPL|any later version|Foundation))|(([Ll]icense|redistribute|released|GNU|GPL|any later version|Foundation).*version 2)" | sed -e 's/:.*//' | sort -u | wc --lines 4042 find -name "*.c" | xargs egrep "(version 2.*([Ll]icense|redistribute|released|GNU|GPL|any later version|Foundation))|(([Ll]icense|redistribute|released|GNU|GPL|any later version|Foundation).*version 2)" | egrep -v '(either version 2(\.[0-9])*|version 2(\.[0-9])*( of the License)*,* or)' | sed -e 's/:.*//' | sort -u | wc --lines 1377 find -name "*.c" | xargs egrep "(version 2.*([Ll]icense|redistribute|released|GNU|GPL|any later version|Foundation))|(([Ll]icense|redistribute|released|GNU|GPL|any later version|Foundation).*version 2)" | egrep -v '(either version 2(\.[0-9])*|version 2(\.[0-9])*( of the License)*,* or)' | sed -e 's/:.*//' | sort -u | xargs grep 'any later version' | wc --lines 4 Hence there are 1377 - 4 = 1373 .c files that explicitely say 'version 2', and 4042 - 1373 = 2669 .c files that say 'version 2 or later'. There are 11100 - 1373 - 2669 = 7058 files that do not say anything. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Fri, Jun 15, 2007 at 08:45:43AM -0700, Linus Torvalds wrote: > I'm sorry, but I've learnt more about copyright law, and talked to more > lawyers about licensing that probably most of the rest of the people > involved in this discussion have *combined*. Which is why I have taken everything you said so far for granted as being a fact -- no need to try to convince me of something ;) In my case it suffices if you say that you are sure (and before anyone says: you're nuts - what I REALLY mean is 'for the purpose of this discussion'. For me, it makes no sense to waste more time on discussing such an issue; I won't bet all my money it, of course). [..snip..] > > I always thought that it would be necessary to get signatures of each > > and every contributor before you can change a license of a file. > > You are mostly correct. The "mostly" comes because I would not say "every > contributor", but would clarify it by saying "every copyright holder". The > difference? Not all contributions are necessarily copyrightable. If you > send in trivial one-liners, we will credit you for them, but that does not > automatically mean that you necessarily own copyright in something. I knew that. > But yes, somebody who wrote an original file (that has some artistic > expression, and isn't just a list of PCI ID's, for example) will be the > copyright owner in that file. Some *very* few people have actually sent me > paperwork to transfer the ownership of copyrights, but they seem to have > done that because they were just used to doing it with the FSF, and I > actually don't care. > > Linus The point is: can you, or can't you (legally) relicense the whole kernel tree under the GPLv3 (or GPLv2+GPLv3)? At first I thought that you cannot, because too many (significant) contributors have been involved (and you will never get signatures from them all). Then someone surprised me by claiming that the original author had copyright for everything - even files added by others. To me, this seemed to say: even if those contributors don't like it, the original author can still sell the whole to some company under a proprietary license (also still having the original under the GPL on the net, of course), as he could do when he was the sole author. Then you reply with: > Carlo> Huh - surely not to files added to the kernel that were written by > Carlo> others from scratch! > Linus> Actually, yes. Even to those - when they are part of "the whole". But the rest of your reply made it a bit unclear again. Assume you stopped taking your meds and next week you think that GPLv3 is THE thing for the kernel. Then could you legally, or can't you, go ahead and change the license of the whole kernel to GPLv3? And if you can't, then roughly how many files / authors are stopping you from doing so? If the answer is: I can't. Then I think you're a lucky bastard, and have escaped years and years of discussions with people trying to convince you that the GPLv3 is better ;) I think that the question: can OTHERS "upgrade" the kernel to GPLv3 has been answered clearly now: No they can't. But if you can, you're probably not done with dealing with people who want that to happen. -- Carlo Wood <[EMAIL PROTECTED]> - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Fri, Jun 15, 2007 at 10:14:44AM +0200, Bernd Paysan wrote: > Linus isn't in the positition to > change that unless he does a substantial change to the file, and also adds > a comment that this file is now GPLv2 only. Which would only have effect on future additions, not the current content of the file - of course. Now - what if someone would write a patch for such a file (that was 'any version' before and then had a header added saying 'just version 2') under the license 'version 2 or later'? This patch could be transformed to 'just 2', and then applied to said source file - but, it could also be added to the previous version of that file (without the new header) as 'version 2 or later'. Hence, the file can still be constructed at any moment (provided the header is removed) as license 'version 2 or later', UNLESS someone adds a *crucial* patch (that cannot be removed as well, along with the header) that is explicitely made version 2 ONLY by its author. Bottom line - adding a header to those files with "version 2 only" by Linus is pointless. -- Carlo Wood <[EMAIL PROTECTED]> - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Fri, Jun 15, 2007 at 06:33:51AM -0400, Daniel Hazelton wrote: > Incorrect. Read section 9 of the GPLv2. It's pretty clear that the "any later > version" clause is optional. Whats more is that since the modern linux kernel > *IS* a "composite work" composed of Linus' original code with changes > contributed by other people - Linus retains copyright to the work as a whole. Huh - surely not to files added to the kernel that were written by others from scratch! > This means that he can license it in any manner he chooses, as long as it > doesn't affect the copyrights (or licensing) of the people that have > contributed changes. I don't have to go to the US copyright law for this - > Linus released Linux under the GPL, others made changes and sent them back > saying "You let me have access to your code under the GPL, I've made some > changes that make it better. You can have my changes under the GPL." QED: > Linus still holds copyright to Linux and can license it in any way he > chooses. This is totally new to me - if this is true - I'd really like to be sure! I always thought that it would be necessary to get signatures of each and every contributor before you can change a license of a file. Why do you think that the FSF demands written copyright-transfers with signatures before you are allowed to submit a patch to any of their largers projects? If they - as original copyright holder - could do what you claim - they wouldn't need those signatures. Having signed a copyright transfer for 'future' changes for gprof, libiberty, readline, zlib, gcc, gdb, libstdc++, bfd, dejagnu, gas, and binutils, Carlo Wood <[EMAIL PROTECTED]> - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thu, Jun 14, 2007 at 11:31:13PM -0300, Alexandre Oliva wrote:
> I know. Neither will Linus. But he says he chose GPLv2 such that he
> could, and the v2 is better than v3 in this regard. What's wrong with
> this picture?
I'm sure it's a rethorical question - but what is wrong is that
imho the clause that normally is added to any file under the GPL
("... version 2 or higher") is builtin in as a safeguard: If, for
whatever reason, in the future it is discovered that the GPL version
X has a flaw that was not forseen - then it can be 'patched' by
writing a successor, having that released by the FSF and allow
anyone to "upgrade" all GPL-ed software to the new license, as
such having avoided the problems of the said (fictious) flaw.
Therefore, it seems pretty weird to me that LONG before version 3
was written and released, someone purposely would choose to freeze
their software at version 2. Why make it "impossible" to use this
safe-guard? ["impossible" because if you get a signature from every
author where they transfer the authorship rights to you, you can
re-release everything under a different license anyway. However,
the kernel has so many authors who never signed anything(?) that
this is not possible anymore].
I never knew it was possible to change the "version 2 or higher" into
"only version 2", but I am not a laywer and not into licenses at all,
and I am sure Linus had laywers look into this, so we can take this
as a fact.
The result is simple:
1) A lot of files in the kernel are fixed at version 2.
2) Version 3 is incompatible with version 2 (which I also take
for granted, having read that in this thread).
Many (or at least important) authors of version-2 files do not
wish to change the license to one that allows it to be transformed
to GPL v3 (ie, add the clause "version 2 or higher". Therefore,
this will not happen.
The result is that it is impossible to accept/add patches that
can not be converted to GPL v2 (ie, which are explicitely version 2
or have the phrase "version 2 or higher").
I think this whole thread has only one purpose:
To "test" if the kernel source is indeed - by LAW - immutable
and fixed to version 2.
Of course, as an unwritten rule, everyone here will respect
Linus' wishes: he is our leader for things like this. But that
is irrelevant when it is about important things like this:
One day he will be gone - and if this license "upgrade" is only
stopped because people see him as a leader, then the discussion
will happen again and again and again - until the software IS
upgraded. This being a one-way lane (once upgraded, you can't
go back) I think it is LOGICAL to do this: 1) Don't upgrade
for as long as possible (possibly forever), 2) Have discussions
like this while Linus is still alive until it is cristal clear that
the kernel can or can not be "upgraded" to version 3 as a result
of the law. And, imho, as I pointed out above - this is already
clear to me (so this thread can end now as far as me is concerned).
Finally - I realize that most people who seem to oppose Linus -
ie Alexandre, and me included, are NOT (perse) in favour of version 3
(I know I am not). The most important purpose of the discussion
is to TEST if someone could force this "upgrade" in the future
when leadership is less clear. So, I think it's good that some
people are willing to take the side of version 3 and try to go
all the way to prove that it's better and/or possible to "upgrade"
etc - as if they REALLY want that.
--
Carlo Wood <[EMAIL PROTECTED]>
-
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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Fri, Jun 15, 2007 at 12:39:19AM +0100, Alan Cox wrote: > > This is the main reason I dislike GPLwhatever: there is no notion > > of "orginal author". You might have written 99% of the code, that > > Every literary work (including thus software) has an author, and that > author has certain rights which are implicit in them being author. Like, they can release/sell the whole thing under some arbitrary other license at their choice. But once you license it with the GPLv2, then you can't stop anyone else (who got it under that license) from using the code under that license anymore, as such it doesn't matter that you are the original author. > > doesn't matter. You have no rights whatsoever once you release > > something under the GPL (no more than ANYOne else). > > Wrong. The author has a collection of rights which vary by jurisdiction > but which are primarily governed by the Berne Convention and its sequels > notably TRIPS. > > > The GPL is nice for the community, and for the users - but very, > > very bad towards it's authors (taking all and every right you might > > have). If John Doe wants to re-release the whole kernel under > > You must be using a different GPL to the rest of us. You actually had me check the license of the linux kernel :p But really - it has this paragraph that I was refering to in most of it's source files: * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. I might be wrong, but I always thought that that meant that John Doe is free to redistribute the software under version 3 of the License, as published by the FSF. There are source files in the kernel without this phrase, ie - they just say: * This file is released under the GPL. But then the paragraph from COPYING kicks in, reading: Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. Any, 'any version' probably includes version 3 as well. Finally, there are file that don't mention the GPL at all, for example kernel/sys.c just says: * Copyright (C) 1991, 1992 Linus Torvalds But - if it weren't GPL-ed then that would be a violation of the GPL-ed of the rest (Nevertheless, I think the license header should be added to those files). > > GPLv3, then all he needs is a website and some bandwidth. > > And a very good lawyer (oh and a GPL3 as there isn't one yet...) I really don't like license discussions - and after reading in the mailinglist FAQ that license posts are taboo here - I was partly annoyed, partly amazed to see this HUGE flood of mails with as subject line "Dual-Licensing Linux Kernel with GPL V2 and GPL V3" I am sorry that I drew the apparently wrong conclusion that GPL V3 is a pressing reality. > Alan -- Carlo Wood <[EMAIL PROTECTED]> - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thu, Jun 14, 2007 at 01:09:46PM -0700, Linus Torvalds wrote: > I'm the original author, and I selected the GPLv2 for Linux. [...] > I'm not going to bother discussing this any more. You don't seem to > respect my right to choose the license for my own code. This is the main reason I dislike GPLwhatever: there is no notion of "orginal author". You might have written 99% of the code, that doesn't matter. You have no rights whatsoever once you release something under the GPL (no more than ANYOne else). The GPL is nice for the community, and for the users - but very, very bad towards it's authors (taking all and every right you might have). If John Doe wants to re-release the whole kernel under GPLv3, then all he needs is a website and some bandwidth. -- Carlo Wood <[EMAIL PROTECTED]> - 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: DRI/AGP on AMD64 based machine
On Thu, Jun 14, 2007 at 11:17:50AM +1000, Dave Airlie wrote: > How do you have a 965G in an amd64 box? does not compute. Why not? It's the ASUS P5B Deluxe motherboard with an Intel P965/ICH8R chipset. The cpu is a QX6700 2.66 GHz, that's an Intel Core 2 Quad Extreme. amd64 is just the architecture, not the brand. It's an all intel machine, if that's what you mean. -- Carlo Wood <[EMAIL PROTECTED]> - 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: DRI/AGP on AMD64 based machine
On Wed, Jun 13, 2007 at 12:29:25PM -0400, Dave Jones wrote: > For the sake of AGP, we only use the on-CPU GART. > The (nvidia) chipset one is ignored. > > If amd64-agp isn't working for you, attach your dmesg. > (You can also confirm its working by running testgart[1]) Hi Dave, I have an amd64 box for which every kernel after 2.6.18 hangs during boot, so I have no dmesg :( I used git bisect to find out where the problem patch is, and assuming bisect works (imho it jumped between versions very weirdly: closing in on the last 6 revisions, it jumped from 2.6.18 to 2.6.18-rc2 to 2.6.18-rc6), the problem is a patch in intel-agp.c, where support for the intel 965G is added (which I have). I mailed the author of the patch, including the git Id of that patch... but he didn't reply... and I didn't keep the mail :/ So, I am afraid I can't give much details. I'd still like to have it sorted out. If you give me the green light (in the sense that you are willing to help a kernel-newbie when needed) then I'll have another attempt at getting more information. -- Carlo Wood <[EMAIL PROTECTED]> PS I believe it was you who committed the patch. - 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: ide0=noprobe, hda=noprobe, hda=none ignored?
keyword: =noprobe, =none, IRQ probe failed, initrd, ide_core, solved, solution, howto. On Mon, Jun 11, 2007 at 05:13:22PM +0600, Alexander E. Patrakov wrote: > If your kernel uses modular IDE drivers and an initrd/initramfs that loads > them, your result is the expected one (i.e.: not a bug). One should add the > following or similar options into /etc/modprobe.conf in the initrd in order > to get the result: > > options ide_core options="ide0=noprobe hda=noprobe hdb=noprobe" > > If you don't use initrd, or have a non-modular IDE driver, please ignore > this message. Thanks! I have indeed an initrd and a modular IDE driver, this was the solution :) Thanks, I really learned from this :) For the sake of archiving, so people can find this solution back with Google and use it too, I've added keywords as first line and will add below all relevant information (this can be ignored by people from the linux-kernel.) 1) If you suffer from this problem and want to know if this solution is for you, use the command 'lsmod' and check if you have ide_core loaded as module: lsmod | grep ide_core 2) Check if you have an initrd in /boot: ls /boot/initrd*`uname -r` 3) Check if you use /etc/modprobe.conf, or /etc/modprobe.d ls -ld /etc/modprobe.conf /etc/modprobe.d if only /etc/modprobe.d exists, it will be what is used, and add a file (I used 'noprobe') to this directory. Otherwise add the line given by Alexander to /etc/modprobe.conf. Thus, echo 'options ide_core options="ide0=noprobe hda=noprobe hdb=noprobe"' >/etc/modprobe.d/noprobe or add that line to your existing /etc/modprobe.conf obviously, replace hda/hdb with the drive ids that you need to be ignored, and ide0 with the corresponding ide# (dmesg | grep hdX, directly after booting, should tell you). I did not test if using only 'ide0=noprobe' or only 'hda=noprobe hdb=noprobe' is sufficient. 4) Regenerate your initrd image (this might depend on the distribution you are using. On debian you'd execute: update-initramfs -u which is part of the initramfs-tools package. 5) If you want to be sure that the option is now in your initrd image, you can do the following: cd /boot mkdir initrd-VERSION-extract cd initrd-VERSION-extract gzip -dc ../initrd.img-VERSION | cpio -i ls etc/ and check if the options line is where you added it in your real root. Ie, if you added it to /etc/modprobe.d/noprobe: cat /boot/initrd-VERSION-extract/etc/modprobe.d/noprobe after that you can rm /boot/initrd-VERSION-extract again, of course. 6) reboot - and enjoy the no probing! Thanks to Alexander E. Patrakov for this solution. -- Carlo Wood <[EMAIL PROTECTED]> - 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/
ide0=noprobe, hda=noprobe, hda=none ignored?
I've been trying for months to get my box to boot faster by ignoring the not connected hda/hdb (ide0). ansset:~>dmesg | egrep '(noprobe|ide0|hda|hdb)' Kernel command line: root=/dev/hde3 ro ide0=noprobe ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:pio, hdb:pio Probing IDE interface ide0... hda: IRQ probe failed (0xfdb8) etc. or Kernel command line: root=/dev/hde3 ro hda=none hdb=none ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:pio, hdb:pio Probing IDE interface ide0... hda: IRQ probe failed (0xfdb8) same for hda=noprobe hdb=noprobe Nothing helps. Is this a bug or not? I'd think that saying "noprobe" means "do NOT probe" - but it probes anyway. The documentation also tells me that =none should CERTAINLY make it ignore the non-existant drives - but it keeps probing. Shouldn't an explicitely added kernel parameter be taken a little bit more serious by the kernel? Independent on whether or not a drive is detected (or what the CMOS might think about that), I think that the kernel should REALLY, totally ignore an ide and/or hdX if so explicitely requested with a kernel parameter. Anything I missed? -- Carlo Wood <[EMAIL PROTECTED]> PS Sorry if this is a FAQ (it seems so) -- I just can't find a satisfactory answer anywhere as to why explicit parameters like this are ignored and want to ask to change this. Or, I cannnot find the solution for this problem and get my damn ide0 NOT probed. - 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/
