Re: 2.6.20.git regression: 'PCI: add the sysfs driver name to all modules' causes hard hang on boot
On Sat, 2007-02-17 at 09:20 +0100, Mike Galbraith wrote: > On Fri, 2007-02-16 at 17:50 -0800, Greg KH wrote: > > On Sat, Feb 17, 2007 at 02:38:08AM +0100, Mike Galbraith wrote: > > > On Fri, 2007-02-16 at 14:36 -0800, Greg KH wrote: > > > > On Fri, Feb 16, 2007 at 10:55:10AM +0100, Mike Galbraith wrote: > > > > > Greetings, > > > > > > > > > > Per $subject, git.yesterday hangs hard on boot here. A git bisect > > > > > fingered the commit below, which I verified via git bisect reset; git > > > > > revert -n 725522b5453dd680412f2b6463a988e4fd148757, after which box > > > > > boots fine. (well, I hope I verified... i'm git-ignorant) > > > > > > > > If you change CONFIG_SYSFS_DEPRECATED to Y, does that solve the problem? > > > > > > It's already set. > > > > It's not set in the config file you sent to me and the list :) > > Oops. (Lysdexic mouse, or friends+Aerosmith+beer+2:30A.M.:) Makes no > difference. Nada from nmi_watchdog either btw. The reason it's hanging is that nobody releases the driver, so we wait forever in driver_unregister(). With the below, box boots fine... --- drivers/base/bus.c.org 2007-02-18 08:38:57.0 +0100 +++ drivers/base/bus.c 2007-02-18 08:39:09.0 +0100 @@ -593,6 +593,7 @@ void bus_remove_driver(struct device_dri driver_detach(drv); module_remove_driver(drv); kobject_unregister(&drv->kobj); + driver_release(&drv->kobj); put_bus(drv->bus); } ...but that can't be right given that the darn thing booted just fine prior to the naming patch with an equally unhappy init_ipmi_si(). Hmm. -Mike - 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: e2b2rom_init_one(): Unable to register resource
No, that's portability bug... Need time for review ;) Cyrill - 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] override build timestamp
On Sun, Feb 18, Roman Zippel wrote: > Hi, > > On Fri, 16 Feb 2007, Olaf Hering wrote: > > > Pass a timestamp to kbuild via an enviroment variable. > > > > TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux > > > > This can be used when the kernel source is in a SCM and uname -v > > is supposed to give the commit date and not the package build time. > > Is this really necessary? I don't really see the point of this. The package/kernel buildtime does not mean much, but the commit date gives you a way to restore the source state for a given binary. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: >> I don't actually think that is what happening. The block errors tend to >> trail a >> bit behind, so the errors you are seeing are probably the result of the queue >> being flushed out as you remove the card. I don't see any mmc debug messages >> that indicate that is trying to send more mmc requests. > > Yes, indeed - it does not issue new requests after remove. However, > mmc_remove_host does not wait > for all issued requests to complete and it is a problem. I don't see how that is possible. mmc_block's remove routine waits for mmcqd to exit, so there can't be any code still alive that has a request going. (I am also completely unable to reproduce this problem here). Add more printk:s do verify how the code in mmc_block executes. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - 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] input: extend EV_LED
On Sun, Feb 18, 2007 at 08:45:00AM +0100, Németh Márton wrote: > > On Fri, 16 Feb 2007, Henrique de Moraes Holschuh wrote: > > On Thu, 15 Feb 2007, Richard Purdie wrote: > > > This has been discussed in several places several times. > The problem > > > with hardware accelerated flashing is that you're are > often limited to > > > certain constraints (this case being no exception) and > indicating what > > > these are to userspace in a generic fashion is difficult. > > > > The hability to blinking at one rate is *very* common on > laptops. Blinking > > at a few discrete rates is also common enough. They > should be supported in > > a generic way. > > [...] > > Here's a suggestion for a simple, non-overengineered > interface: a "blink" > > attribute (on/off) for leds which can hardware-blink. > Only one blink > > frequency is common enough that this attribute by itself > is very useful > > (e.g. it is all a ThinkPad and most WiFi/network card leds > need). > > > > For hardware-blink leds with various frequencies, there is > the typical way > > to provide such things: give us a RO > blink_available_frequencies attribute > > which says which discrete frequencies are allowed (space > separated), and a > > RW blink_frequency attribute to set the frequency. If > instead of > > blink_available_frequencies, the driver provides RO > blink_frequency_min and > > _max attributes, then it means it can blink on that range > of freqs. > > > > That is simple enough to implement and use, and generic > enough. You just > > need to set in stone if you want the freq in Hz, or a > submultiple. You can > > even implement an optional "blink" software emulation that > drivers can hook > > into for systems where the driver *knows* that led access > is fast, but there > > is no hardware blinking emulation. > > > > A blinking led is basically a PWM (Pulse Width Modulation) > signal. A PWM signal has three different attribute. The > first one is the amplitude, this attribute is already > provided by the led subsystem as "brightness". There are two > more attributes, which are the frequency [Hz] and the duty > cycle [%], or the on-time [ms] and off-time [ms]. > > The frequency [Hz] and duty cycle [%] parameters has the > problem, that if we are limited to integers, it is not > possible to express slower blinks than 1Hz. We could also > use [mHz] (milli-Hertz), but it is not very common unit. > > The on-time [ms] and off-time [ms] seems to be easier to > handle (and this is also easier to simulate from software if > ever needed). An RO attribute could be introduced: > 'pwm_available', which can contain parameter pairs separated > by space, and the new parameter pair is in new line. An RW > attribute 'pwm' could accept a parameter pair separated by > space. > > A range could be also given in 'pwm_available', like this: > '500-1000 500-1000'. This has the limitation that if there > is a hardware which can blink a LED in differet freqencies, > but only with fixed 50% duty cycle, the on-time off-time > pair cannot express this range easily. > > My real-world example would be my Clevo D4J (D410J) > notebook's mail led. It has three known state: off, PWM at > 1Hz (50%), PWM at 0.5Hz (50%). In case the on-time [ms] > off-time [ms] parameter pairs are used: > > $ cat pwm_available > 500 500 > 1000 1000 > > What is your opinion? Maybe you should consider that if there's only one parameter, it implies both on- and off- times, leading to a duty cycle of 50% ? It would also make it easier to get and set the frequency when the duty cycle is assumed to be 50%. Also, I'm not sure that a resolution of 1ms really is appropriate, in case you encounter hardware with better resolution. With ms, at high blink rates (>=100 Hz), you're bound to 500,333,250,200,166,142,125,111,100 Hz, which does not give you much control over the duty cycle for devices with a high frequency. Maybe you should express the on- and off- times in microseconds ? Just my two cents anyway since I'm not directly concerned by such devices. Regards, Willy - 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.20-git13 kernel BUG at /mnt/md0/devel/linux-git/kernel/time/tick-sched.c:168
On Sat, 2007-02-17 at 23:41 +0100, Michal Piotrowski wrote: > sudo cat /var/log/messages | grep Idle > Feb 17 17:35:34 bitis-gabonica kernel: Idle: local softirq pending: > 0020<6>hdd: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, > UDMA(33) > Feb 17 19:20:01 bitis-gabonica kernel: Idle: local softirq pending: > 0020<3>Idle: local softirq pending: 0020<3>Idle: local softirq > pending: 0020<7>PM: Removing info for No Bus:vcs7> > > I can confirm that this is ICH5 SATA controller problem. The arch/i386/kernel/process.c part of the patch should apply to 2.6.20 as well. Can you check if the problem is there too ? tglx - 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: GPL vs non-GPL device drivers
> From: "Michael K. Edwards" > Newsgroups: gmane.linux.kernel > Subject: Re: GPL vs non-GPL device drivers > Date: Sat, 17 Feb 2007 22:56:00 -0800 [] > How are you going to like being forced to fork the entire GNU corpus in > whatever state it's in the day before the v3 conversion hits SVN? Xorg > is going to look like a cakewalk by comparison. Don't worry, just help ;) Ulrich Drepper is known to be against current FSF's position on glibc licence changing. Linus Torvalds has wrote sparse, which got it's maintainer. Maybe Google, if it will, will do some job(backend) to get GCS (Google Compiling Serivice ;), no need in compiler here (tm;). Jeff Garzik doing his POSIX utilites. There are many other alternatives to GNU software, and they are working and being maintained, being "nongnu.org" or in their open source zoos, rather than in savannah(.gnu.org (: - dash / busybox (rip GNU bash) - builders (many, rip GNU make) - s-lang lib (rip GNU ncurses) - jed, Xemacs (rip GNU Emacs) After making live alternative to GNU software, you may *say* and *do* everything you like against it. Indeed, i think Linux Kernel club is one of such creatures (not with bull's head ;) So, as you can see it's OK. Just grab your "non-GNU-Emacs" and join the club! Cheers. p.s. i can be very naive, of course. -- -o--=O`C info emacs : not found /. .\ ( is there any reason to live? ) #oo'L O info make : not found o (yes --- R.I.P. FSF+RMS) <___=E M man gcc: not found`-- ( viva Debian Operating System ) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial and tty driver
Thank you for you respond. I asked this question since I have one problem with my tty driver. It based on serial_core.c. It works well except Linux cat operation:(. (e.g. cat < ttyS10). I thought in tty driver there is no function for this operation and I wanted to know that maybe serial driver has it. Could it be the reason that cat operation in tty driver does not work (but I can write and read from user space application!)? Or maybe I need to implement a special function in my tty driver to support Linux cat operation? Thank you again >On Sat, Feb 17, 2007 at 12:24:22PM -0600, Paul Fulghum wrote: >> Mockern wrote: >> >I have a question, what is really difference between serial and tty >> >drivers? >> > >> >As I understand tty is high level and communicates with user space. >> >> The serial core implements many of the details of a tty >> driver in a common place so that individual hardware drivers >> (serial drivers) only need implement the hardware specific code. >> >> This prevents duplicating tty logic in many drivers, >> with the possibility of mistakes/inconsistency in the >> different tty drivers. >> >> The stand alone tty drivers are mostly legacy code from >> the time before serial core that have not been ported >> to be a serial drivers. > >Not necessarily; there are a number of tty drivers, such as the >console drivers and pseudo-tty drivers that have absolutely nothing to >do with an RS-232 port. > >On the other side of the argument, another factorization of the layers >that might have made sense was to move the functionality to the >high-level tty layer (or in the case of hangup code, all the way up to >the VFS layer as a generic sys_revoke functionality), but the reason >why it didn't is largely historical. > > - Ted >- >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/ -- Яндекс.Почта: объем почтового ящика не ограничен! http://mail.yandex.ru/monitoring/ - 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: ADC driver with I2C interface
Thank you, I'll take a look. > >did you tried www.comedi.org ? > >Am Sunday 18 February 2007 00:18 schrieb Mockern: >> Hello, >> >> Where I can grab an example of ADC driver with I2C interface? >> - >> 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/ -- Яндекс.Почта: объем почтового ящика не ограничен! http://mail.yandex.ru/monitoring/ - 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: GPL vs non-GPL device drivers
On Sunday 18 February 2007 00:55, Michael K. Edwards wrote:
> Or they could run:
> find . -type f -exec
perl -i.bak -pe 's/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g'
> and be done with it. Or even just MODULE_LICENSE("GPL") in their
> module -- that's not "lying about the module license", it's "doing the
> minimum necessary in order to interoperate efficiently with the
> kernel". Atari v. Nintendo is still good law, but only to the
> extent that it does not conflict with Lexmark, which now has the seal
> of Supreme Court approval. And (IMHO, IANAL) if writing
> MODULE_LICENSE("GPL") is obviously the only remotely efficient way to
> achieve the goal of interoperation with the kernels that people
> already have on their systems
Except that this is not about a driver that is supposed to interoperated
with the kernels people already have on their systems. This is about
shipping new (embedded) systems with a modified (if you go the s/_GPL//g
route, even more so) Linux kernel, and distribution a modified kernel *has*
to comply with the GPL, since this is *exactly* what the GPL is about:
redistribution of modified copies of the work.
--
Giuseppe "Oblomov" Bilotta
-
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: [RFC] Time for a linux-kvm mailing list?
Bill Davidsen wrote: There doesn't seem to be a great place for KVM user questions, this is it, and kvm-devel seems a poor place for user questions, while the chat room is real time and depends on the question and the answer being in the same place at the same time. kvm-devel is perfectly suitable for user queries. Just a thought on getting a dialogue going in the right place. You could have started by posting your idea on kvm-devel, where kvm developers and users would actually see it. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - 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.20.git regression: 'PCI: add the sysfs driver name to all modules' causes hard hang on boot
On Sun, 2007-02-18 at 09:02 +0100, Mike Galbraith wrote: > The reason it's hanging is that nobody releases the driver, so we wait > forever in driver_unregister(). With the below, box boots fine... > > --- drivers/base/bus.c.org2007-02-18 08:38:57.0 +0100 > +++ drivers/base/bus.c2007-02-18 08:39:09.0 +0100 > @@ -593,6 +593,7 @@ void bus_remove_driver(struct device_dri > driver_detach(drv); > module_remove_driver(drv); > kobject_unregister(&drv->kobj); > + driver_release(&drv->kobj); > put_bus(drv->bus); > } > > > ...but that can't be right given that the darn thing booted just fine > prior to the naming patch with an equally unhappy init_ipmi_si(). Hmm. Ok. The path it's supposed to take to driver_release() goes like so [ 17.495312] bus platform: add driver ipmi [ 17.506560] ipmi message handler version 39.1 [ 17.518099] ipmi device interface [ 17.528491] device class 'ipmi': registering [ 17.539854] bus platform: add driver ipmi_si [ 17.551210] IPMI System Interface driver. [ 17.562242] bus pci: add driver ipmi_si [ 17.583686] bus pci: remove driver ipmi_si [ 17.594721] BUG: at drivers/base/bus.c:65 driver_release() [ 17.607224] [] show_trace_log_lvl+0x1a/0x30 [ 17.619434] [] show_trace+0x12/0x14 [ 17.630822] [] dump_stack+0x16/0x18 [ 17.642098] [] driver_release+0x37/0x39 [ 17.653703] [] kobject_cleanup+0x43/0x64 [ 17.665359] [] kobject_release+0xb/0xd [ 17.676748] [] kref_put+0x28/0x8c [ 17.687626] [] kobject_put+0x14/0x16 [ 17.698712] [] kobject_unregister+0x22/0x25 [ 17.710359] [] bus_remove_driver+0x95/0xa5 [ 17.721911] [] driver_unregister+0xe/0x47 [ 17.733317] [] pci_unregister_driver+0x13/0x73 [ 17.745149] [] init_ipmi_si+0x798/0x7ba [ 17.756339] [] init+0x114/0x23c [ 17.766748] [] kernel_thread_helper+0x7/0x1c ...so I guess it's a ref counting problem somewhere. -Mike - 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.18.6 OK, 2.6.19.3 & 2.6.20 NOT
2.6.18.6 vanilla: /dev/hda CD/DVD /dev/hda1 / IDE HD 160GB /dev/hda2 swap /dev/sda1 /xyz SATA HD 320GB /dev/sda2 swap /dev/sdb1 /zzz SATA HD 320GB /dev/sdb2 swap /dev/sdc1 /usb USB KEY 512MB all 100% OK since 12-Dec-2006 2.6.19.3 vanilla & 2.6.20 vanilla, identical behaviour: /dev/hda, /dev/hdb OK fsck 1.38 (30-Jun-2005) /dev/sda1: clean 2960/125696 files, 12379/125692 blocks but /dev/sda1 is only partially mounted, du -hs says 33M ... /sbin/e2fsck: No such file or directory while trying to open /dev/sdb1 ... same for /dev/sdc1 ... swapon: cannot stat /dev/sda2: No such file or directory same for /dev/sdb2, so only 2GB swap, not 6GB AUSUS P4R800V, P4HT3400, 2GB mem Slackware 11.0, udev-105, gcc-3.4.6, lib-2.3.6, all ext2 formated Rebooting 2.6.18.6: /dev/sda1: clean 4434650/77004800 files, 76977447/76977447 blocks (disk is full, I know), all OK, 6GB swap FEEDBACK ONLY, _not_ in LMKL Kind regards Mario Vanoni - 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 00/14] Syslets, generic asynchronous system call support, v2
On Thu, 15 Feb 2007 17:51:51 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > this is the v2 release of the syslet subsystem. This is an interim > release, not all known and pending items are fixed/changed yet - the > tree is still work in progress: > >http://redhat.com/~mingo/syslet-patches/ So, has anyone thought about all those 32bit processes running on a 64bit kernel and how we are going to cope with this interface? -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp83MPipt0B6.pgp Description: PGP signature
Re: Kbuild problem
On Sun, Feb 18, 2007 at 12:22:10AM -0500, Kai Germaschewski wrote: > On Sat, 17 Feb 2007, Tilman Schmidt wrote: > > > Alright, then so be it. But that raises another question: > > asyncdata.o is only needed for M105 and M101, not for the base > > driver. How do I express in Kbuild that asyncdata.o is to be added > > to gigaset-y only if CONFIG_GIGASET_M105 and CONFIG_GIGASET_M101 > > are not both 'n'? > > The way this is typically done is via Kconfig. Add a config option > ASYNCDATA (actually something more descriptive/specific would be better), > add a "select ASYNCDATA" to the config options for m101 and m105, and then > you can use CONFIG_ASYNCDATA to decide whether to add asyncdata.o in the > Makefile. One disadvantage of this approach is that in a kernel with CONFIG_GIGASET_BASE=y, you can't later compile and load the usb_gigaset or ser_gigaset modules without rebooting since they require a change to the kernel image. > --Kai cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.20-mm1 - Oops using Minix 3 file system
2007/2/17, Cédric Augonnet <[EMAIL PROTECTED]>: 2007/2/17, Bill Davidsen <[EMAIL PROTECTED]>: > Cédric Augonnet wrote: That is my all point actually, i am not telling i have a valid partition. I'm just describing the fact that the minix fs driver is making too many assumptions on the partition it is given. For sure there must be something nasty about this image, as you told this is the duty of the kernel not to mount such a partition if it is not a partition. Here I was only giving an example of the way we could trick the driver. This is as important as having the driver working correctly on valid partitions i suppose. Eventually the problem got solved by Andries Bouwer : http://marc.theaimsgroup.com/?l=linux-mm-commits&m=117176125510900&w=2 Now i can issue a df command on this partition or whatever it may be, and i obtain a consistent result wiythout any oops. Regards, Cédric - 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: e2b2rom_init_one(): Unable to register resource
On Sat, Feb 17, 2007 at 11:29:19PM +0200, Dan Aloni wrote: | Hello, | | I'm running the x86_64 arch of Linux 2.6.20 on a Supermicro X6DH8-XG2 | board and I got this during boot: | | [248660.950695] device id = 2440 | [248660.950699] device id = 2480 | [248660.950703] device id = 24c0 | [248660.950706] device id = 24d0 | [248660.950709] matched device = 24d0 | [248660.950712] matched device id 24d0 | [248660.950716] pci_read_config_byte : 4 | [248660.950723] esb2rom: esb2rom_init_one(): Unable to register resource | 0xffc0-0x - kernel bug? | [248660.950729] esb2rom: ioremap(ffc0, 10040) failed | [248660.956859] retVal = -19 | | Looks like some kind of a 64-bit portability bug... | | -- | Dan Aloni | XIV LTD, http://www.xivstorage.com | da-x (at) monatomic.org, dan (at) xiv.co.il | - | 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/ | Hi, here is a patch attached to the mail. You may test it. Actually I have no 64bit machine to test it and I'm worried about the patch accuracy. So be carefull testing it. I sent a copy of the message to Andi Kleen (who is a maintainer of X86-64 port) may be we should wait for its answer ;) Cyrill diff --git a/drivers/mtd/maps/esb2rom.c b/drivers/mtd/maps/esb2rom.c index a9d808a..d63c060 100644 --- a/drivers/mtd/maps/esb2rom.c +++ b/drivers/mtd/maps/esb2rom.c @@ -214,6 +214,9 @@ static int __devinit esb2rom_init_one(struct pci_dev *pdev, /* reserved 0x0020 and 0x0010 */ window->phys -= 0x40UL; +#ifdef CONFIG_64BIT + window->phys &= 0xUL; +#endif window->size = (0xUL - window->phys) + 1UL; /* Enable writes through the rom window */
Re: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug
On Sunday, 18 February 2007 00:42, Oleg Nesterov wrote:
> On 02/17, Rafael J. Wysocki wrote:
> >
> > On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
> > >
> > > static inline int is_user_space(struct task_struct *p)
> > > {
> > > return p->mm && !(p->flags & PF_BORROWED_MM);
> > > }
> > >
> > > This doesn't look right. First, an exiting task has ->mm == NULL after
> > > do_exit()->exit_mm(). Probably not a problem. However, PF_BORROWED_MM
> > > check is racy without task_lock(), so we can have a false positive as
> > > well. Is it ok? We can freeze aio_wq prematurely.
> >
> > Right now aio_wq is not freezeable (PF_NOFREEZE).
>
> Right now yes, but we are going to change this?
Well, is there any more reliable (and not racy) method of differentiating
between kernel threads and user space processes?
> > > cancel_freezing(p);
> > > continue;
> > >
> > > Is it right? Shouldn't we increment "todo" counter?
> >
> > No. It would be wrong to do that, because TASK_TRACED tasks with frozen
> > parents cannot be frozen any further.
>
> TASK_TRACED task could be woken by SIGKILL. cancel_freezing() clears
> TIF_FREEZE.
> The task may start do_exit() when try_to_freeze_tasks() returns "success".
> Probably not a problem.
Yup.
Greetings,
Rafael
-
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: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug
On Sunday, 18 February 2007 00:47, Oleg Nesterov wrote: > On 02/18, Oleg Nesterov wrote: > > > > On 02/17, Rafael J. Wysocki wrote: > > > > > > Alternatively, we can move the check into refrigerator(), like this: > > > > > > --- linux-2.6.20-git13.orig/kernel/power/process.c > > > +++ linux-2.6.20-git13/kernel/power/process.c > > > @@ -39,6 +39,11 @@ void refrigerator(void) > > > /* Hmm, should we be allowed to suspend when there are realtime > > > processes around? */ > > > long save; > > > + > > > + /* Freeze the task unless there is a vfork completion pending */ > > > + if (current->vfork_done) > > > + return; > > > + > > > > This means that "current" returns to user space (get_signal_to_deliver > > will clear TIF_SIGPENDING) and runs. While try_to_freeze_tasks() thinks > > it is frozen. > > Ah, sorry. I am wrong, current has no PF_FROZEN yet. > > However, this means that sys_vfork() makes impossible to freeze processes > until child exits/execs. Not good. Yes, but this also is the current behavior. I think the real solution would be to use an interruptible completion in the vfork code. It was discussed some time ago and, IIRC, Ingo had an experimental patch that implemented it. Still, for the suspend this really is not an issue in practice, so it wasn't merged. It may be a good time to solve this problem now. :-) Greetings, Rafael - 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] input: extend EV_LED
On Fri, 2007-02-16 at 01:12 -0200, Henrique de Moraes Holschuh wrote: > On Thu, 15 Feb 2007, Richard Purdie wrote: > > This has been discussed in several places several times. The problem > > with hardware accelerated flashing is that you're are often limited to > > certain constraints (this case being no exception) and indicating what > > these are to userspace in a generic fashion is difficult. > > The hability to blinking at one rate is *very* common on laptops. Blinking > at a few discrete rates is also common enough. They should be supported in > a generic way. I just said that finding a way to do it generically is difficult, not that we shouldn't do it. > I want to convert ibm-acpi to the led interface, but if it means I have to > provide custom attributes on top of the led class, it sort of defeats most > of the purpose of using the led class to begin with -- it will NOT be > generic. Even if half your functionality is exposed through the class, that half that is standardised rather than adhoc. Having said that, you shouldn't need any custom attributes though. > If I have to provide those attributes elsewhere in the sysfs tree other than > somewhere in the led class, then it defeats the purpose of using the led > class completely: I will just scrap the idea. I am not going to remove > functionality. And I am not going to emulate in software something the > hardware can do, especially when that means bothering the EC with a slow > ACPI-subsystem-gated LPC bus IO port access for no good reason. > > Here's a suggestion for a simple, non-overengineered interface: a "blink" > attribute (on/off) for leds which can hardware-blink. Only one blink > frequency is common enough that this attribute by itself is very useful > (e.g. it is all a ThinkPad and most WiFi/network card leds need). Right, but blinking is not an LED attribute but more of an action for the LED so what we need is an LED blink trigger. Rather than the timer trigger which takes a variety of options, this blink trigger could just take an on/off value. In the absence of hardware capability, we can emulate it. I like the idea of a simple blink trigger... > For hardware-blink leds with various frequencies, there is the typical way > to provide such things: give us a RO blink_available_frequencies attribute > which says which discrete frequencies are allowed (space separated), and a > RW blink_frequency attribute to set the frequency. If instead of > blink_available_frequencies, the driver provides RO blink_frequency_min and > _max attributes, then it means it can blink on that range of freqs. This is quite complex and whilst we could certainly have a trigger that did this, we already have a variable frequency trigger. See below. > That is simple enough to implement and use, and generic enough. You just > need to set in stone if you want the freq in Hz, or a submultiple. You can > even implement an optional "blink" software emulation that drivers can hook > into for systems where the driver *knows* that led access is fast, but there > is no hardware blinking emulation. If a trigger/attribute appears for an LED, its behaviour needs to be the same for all LEDs. > > One way I've come up with is adds capability to the class to have LED > > specific triggers and you can then expose these hardware capabilities as > > an extra trigger specific to the LED. > > How would that look like? It doesn't sound too bad. Could you give us an > example of what the tree would look like, and what the attributes would be > (and do)? > > > Another proposal more specific to this use case was to have some > > information behind the scenes which the software timer based trigger > > could use to turn on the "hardware acceleration" if present and capable > > of the requested mode. This might just need a function pointer in the > > core so could be quite neat. > > This looks like a severely overengineered way to deal with the problem at > first glance. Which means you haven't thought about it as its quite simple in software terms. The LED driver can optionally implement a couple of functions: set_blink(enum frequency) set_blink_frequency(int delay_on, int delay_off) These are not exported as an attribute directly and are just something triggers can use. Any trigger needing blinking behaviour calls one of these functions as appropriate and if implemented. The enum reflects a spectrum of loosely defined frequencies, a bit like brightness maybe in a range 0-6. The idea is these are loose definitions and the driver will attempt a loose match, using any hardware blinking if available. In the case of an LED with a full blown PWM capability (which can support near enough any frequency), it could just implement set_blink_frequency() and the LED core could provide a set_blink() function which translated into a call to set_blink_frequency() with some predefined frequency defaults. If it didn't support the parameters passed, it returns an error which th
Re: [PATCH] KVM SVM: intercept SMI to handle it at host level
Joerg Roedel wrote: From: Joerg Roedel <[EMAIL PROTECTED]> This patch changes the SVM code to intercept SMIs and handle it outside the guest. Applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - 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: e2b2rom_init_one(): Unable to register resource
On Sun, Feb 18, 2007 at 01:42:22PM +0300, Cyrill Gorcunov wrote: > Hi, > > here is a patch attached to the mail. You may test it. Actually > I have no 64bit machine to test it and I'm worried about the > patch accuracy. So be carefull testing it. I sent a copy of the > message to Andi Kleen (who is a maintainer of X86-64 port) may be > we should wait for its answer ;) Thanks, I'll give it a try soon. BTW, wouldn't it be better just to change the type of phys and size to u32? > diff --git a/drivers/mtd/maps/esb2rom.c b/drivers/mtd/maps/esb2rom.c > index a9d808a..d63c060 100644 > --- a/drivers/mtd/maps/esb2rom.c > +++ b/drivers/mtd/maps/esb2rom.c > @@ -214,6 +214,9 @@ static int __devinit esb2rom_init_one(struct pci_dev > *pdev, > > /* reserved 0x0020 and 0x0010 */ > window->phys -= 0x40UL; > +#ifdef CONFIG_64BIT > + window->phys &= 0xUL; > +#endif > window->size = (0xUL - window->phys) + 1UL; > > /* Enable writes through the rom window */ -- Dan Aloni XIV LTD, http://www.xivstorage.com da-x (at) monatomic.org, dan (at) xiv.co.il - 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 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 2/17/07, Paul Mundt <[EMAIL PROTECTED]> wrote: On Sat, Feb 17, 2007 at 08:25:07AM -0500, Jaya Kumar wrote: > On 2/17/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote: > >And, as Andrew suggested last time around, could you perhaps push this > >fancy new idea into the FB layer so that more drivers can make us of it? > > I would like to do that very much. I have some ideas how it could work > for devices that support clean partial updates by tracking touched > pages. But I wonder if it is too early to try to abstract this out. > James, Geert, what do you think? > This would also provide an interesting hook for setting up chained DMA for the real framebuffer updates when there's more than a couple of pages that have been touched, which would also be nice to have. There's more than a few drivers that could take advantage of that. Hi Paul, I could benefit from knowing which driver and display device you are considering to be applicable. I was thinking the method used in hecubafb would only be useful to devices with very slow update paths, where "losing" some of the display activity is not an issue since the device would not have been able to update fast enough to show that activity anyway. What you described with chained DMA sounds different to this. I suppose one could use this technique to coalesce framebuffer IO to get better performance/utilization even for fast display devices. Sounds interesting to try. Did I understand you correctly? Thanks, jaya - 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: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug
On 02/18, Rafael J. Wysocki wrote: > > On Sunday, 18 February 2007 00:47, Oleg Nesterov wrote: > > > > However, this means that sys_vfork() makes impossible to freeze processes > > until child exits/execs. Not good. > > Yes, but this also is the current behavior. Yes, yes, I see. I forgot to say that we have another problem: coredumping. A thread which does do_coredump() send SIGKILL to ->mm users, and sleeps on ->mm->core_startup_done. Now it can't be frozen if sub-thread goes to refrigerator. I think this could be solved easily if we add a check to refrigerator() as you suggested for ->vfork_donw. > I think the real solution would be to use an interruptible completion in the > vfork code. It was discussed some time ago and, IIRC, Ingo had an > experimental > patch that implemented it. Still, for the suspend this really is not an issue > in practice, so it wasn't merged. It is not (afaics) so trivial to do rightly, and with this change the parent will be seen as TASK_INTERRUPTIBLE even without freezer in progress. A very vague idea: what if parent will do current->flags |= PF_PLEASE_CONSIDER_ME_AS_FROZEN_BUT_SET_TIF_FREEZE wait_for_completion(&vfork); try_to_freeze(); ? > It may be a good time to solve this problem now. :-) Yes, I think so :) Oleg. - 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: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug
On 02/18, Rafael J. Wysocki wrote:
>
> On Sunday, 18 February 2007 00:42, Oleg Nesterov wrote:
> > On 02/17, Rafael J. Wysocki wrote:
> > >
> > > On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
> > > >
> > > > static inline int is_user_space(struct task_struct *p)
> > > > {
> > > > return p->mm && !(p->flags & PF_BORROWED_MM);
> > > > }
> > > >
> > > > This doesn't look right. First, an exiting task has ->mm == NULL after
> > > > do_exit()->exit_mm(). Probably not a problem. However, PF_BORROWED_MM
> > > > check is racy without task_lock(), so we can have a false positive as
> > > > well. Is it ok? We can freeze aio_wq prematurely.
> > >
> > > Right now aio_wq is not freezeable (PF_NOFREEZE).
> >
> > Right now yes, but we are going to change this?
>
> Well, is there any more reliable (and not racy) method of differentiating
> between kernel threads and user space processes?
Not that I know of. At least, we can take task_lock() to really rule out
kernel threads at FREEZER_USER_SPACE stage.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PROBLEM] compiling latest linus-upstream
Hi all, I just tried to compile Torvald's upstream-linus and ran into a compile error. CC arch/i386/kernel/time.o In file included from include/asm-i386/mach-default/do_timer.h:5, from arch/i386/kernel/time.c:75: include/asm/i8253.h: In function `pit_interrupt_hook': include/asm/i8253.h:18: error: dereferencing pointer to incomplete type make[1]: *** [arch/i386/kernel/time.o] Error 1 make: *** [arch/i386/kernel] Error 2 The pull is done 5 minutes ago. I attached my .config file, patrick # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20 # Fri Feb 16 19:58:22 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_LSF=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="deadline" # # Processor type and features # CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_X86_MCE_P4THERMAL is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=y CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set # CONFIG_NOHIGHMEM is not set # CONFIG_HIGHMEM4G is not set CONFIG_HIGHMEM64G=y CONFIG_PAGE_OFFSET=0xC000 CONFIG_HIGHMEM=y CONFIG_X86_PAE=y CONFIG_NEED_NODE_MEMMAP_SIZE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_
Re: [PROBLEM] compiling latest linus-upstream
On 2/18/07, Patrick Ale <[EMAIL PROTECTED]> wrote: Hi all, I just tried to compile Torvald's upstream-linus and ran into a compile error. Disregard, I ran make oldconfig again, didnt get prompted for any configuration options, and now it does compile. Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Documentation: Ask driver writers to provide suspend/resume support
Hi! > > > Looks ok. (BTW you have my ACK). > > > > Thanks. > > Anyway, please have a look at the appended revised version. I have separated > the driver testing and debugging documents and changed the paragraph in > SubmittingDrivers a bit. Looks ok to me, but this time I've only scanned it quickly. Thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
Zachary Amsden wrote: Jeremy Fitzhardinge wrote: The XEN config option enables the Xen paravirt_ops interface, which is installed when the kernel finds itself running under Xen. (By some as-yet fully defined mechanism, implemented in a future patch.) Xen is no longer a sub-architecture, so the X86_XEN subarch config option has gone. The disabled config options are: - PREEMPT: Xen doesn't support it - HZ: set to 100Hz for now, to cut down on VCPU context switch rate. This will be adapted to use tickless later. - kexec: not yet supported Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Signed-off-by: Ian Pratt <[EMAIL PROTECTED]> Signed-off-by: Christian Limpach <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> We do support different HZ values, although 100HZ is actually preferable for us, so I don't object to that. Ditto for kvm. PREEMPT is supported by us, but not as tested as I would like, so I also don't object to dropping it for generic paravirt guests - Rusty - Avi any objections to dropping preempt in terms of lguest/KVM paravirtualization? I don't have any objections myself, but Ingo (who has done the bulk of the kvm paravirt work; cc'ed) uses PREEMPT_RT, so he will certainly object. Paravirt-ops definitely needs a hook for kexec, although we should not disable kexec for the natively booted paravirt-ops. Eric - is there a way to disable it at runtime? kvm paravirt should work correctly with kexec. We do support the doublefault task gate, and it would be good to keep it, but I can't complain so much if it is gone from generic paravirt kernels for now, because it is non-essential, and generally fatal anyway. We do need it for native boots of paravirt-ops kernels, however, so turning off the config option still needs to be revisited. kvm doesn't support task gates (a task switch will immediately kill the guest). -- error compiling committee.c: too many arguments to function - 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] input: extend EV_LED
On Sun, 2007-02-18 at 08:45 +0100, Németh Márton wrote: > A blinking led is basically a PWM (Pulse Width Modulation) > signal. A PWM signal has three different attribute. The > first one is the amplitude, this attribute is already > provided by the led subsystem as "brightness". There are two > more attributes, which are the frequency [Hz] and the duty > cycle [%], or the on-time [ms] and off-time [ms]. > > The frequency [Hz] and duty cycle [%] parameters has the > problem, that if we are limited to integers, it is not > possible to express slower blinks than 1Hz. We could also > use [mHz] (milli-Hertz), but it is not very common unit. > > The on-time [ms] and off-time [ms] seems to be easier to > handle (and this is also easier to simulate from software if > ever needed). An RO attribute could be introduced: > 'pwm_available', which can contain parameter pairs separated > by space, and the new parameter pair is in new line. An RW > attribute 'pwm' could accept a parameter pair separated by > space. We already have a timer trigger which takes an on time and an off time for the reason you mention above (floating point would get ugly). The problem is mainly about finding ways to enable hardware acceleration of the existing timer trigger (where possible) and maybe implementing a simpler blink trigger which could be hardware accelerated when the full blown timer trigger couldn't. Regards, Richard - 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: [mmc] incorrect behavior on resume
> I don't see that - as I say above, the correct sequence is: > > - host device resume > - calls mmc_resume_host() > - child's device resume (mmc_blk_resume) > - mmc_queue_resume() > Of course, I understand that this is a correct sequence. It simply was not obvious to me that host will issue requests even if mmc_resume_host is not called. I'm trying to implement a hotplugable host, so I assumed that if host was removed during the suspended state there's no need to resume it. Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 - 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: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug
On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote: > On 02/18, Rafael J. Wysocki wrote: > > > > On Sunday, 18 February 2007 00:47, Oleg Nesterov wrote: > > > > > > However, this means that sys_vfork() makes impossible to freeze processes > > > until child exits/execs. Not good. > > > > Yes, but this also is the current behavior. > > Yes, yes, I see. > > I forgot to say that we have another problem: coredumping. > > A thread which does do_coredump() send SIGKILL to ->mm users, and sleeps > on ->mm->core_startup_done. Now it can't be frozen if sub-thread goes to > refrigerator. I think this could be solved easily if we add a check to > refrigerator() as you suggested for ->vfork_donw. > > > I think the real solution would be to use an interruptible completion in the > > vfork code. It was discussed some time ago and, IIRC, Ingo had an > > experimental > > patch that implemented it. Still, for the suspend this really is not an > > issue > > in practice, so it wasn't merged. > > It is not (afaics) so trivial to do rightly, and with this change the parent > will be seen as TASK_INTERRUPTIBLE even without freezer in progress. > > A very vague idea: what if parent will do > > current->flags |= PF_PLEASE_CONSIDER_ME_AS_FROZEN_BUT_SET_TIF_FREEZE > wait_for_completion(&vfork); > try_to_freeze(); > > ? This should work, but we'll need a separate process flag for it. If that's acceptable, I'd call it PF_VFORK_PARENT Greetings, Rafael - 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: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug
On Sunday, 18 February 2007 12:32, Oleg Nesterov wrote:
> On 02/18, Rafael J. Wysocki wrote:
> >
> > On Sunday, 18 February 2007 00:42, Oleg Nesterov wrote:
> > > On 02/17, Rafael J. Wysocki wrote:
> > > >
> > > > On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
> > > > >
> > > > > static inline int is_user_space(struct task_struct *p)
> > > > > {
> > > > > return p->mm && !(p->flags & PF_BORROWED_MM);
> > > > > }
> > > > >
> > > > > This doesn't look right. First, an exiting task has ->mm == NULL after
> > > > > do_exit()->exit_mm(). Probably not a problem. However, PF_BORROWED_MM
> > > > > check is racy without task_lock(), so we can have a false positive as
> > > > > well. Is it ok? We can freeze aio_wq prematurely.
> > > >
> > > > Right now aio_wq is not freezeable (PF_NOFREEZE).
> > >
> > > Right now yes, but we are going to change this?
> >
> > Well, is there any more reliable (and not racy) method of differentiating
> > between kernel threads and user space processes?
>
> Not that I know of. At least, we can take task_lock() to really rule out
> kernel threads at FREEZER_USER_SPACE stage.
Something like this?
---
kernel/power/process.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
Index: linux-2.6.20-mm2/kernel/power/process.c
===
--- linux-2.6.20-mm2.orig/kernel/power/process.c
+++ linux-2.6.20-mm2/kernel/power/process.c
@@ -8,6 +8,7 @@
#undef DEBUG
+#include
#include
#include
#include
@@ -92,7 +93,12 @@ static void cancel_freezing(struct task_
static inline int is_user_space(struct task_struct *p)
{
- return p->mm && !(p->flags & PF_BORROWED_MM);
+ int ret;
+
+ task_lock(p);
+ ret = p->mm && !(p->flags & PF_BORROWED_MM);
+ task_unlock(p);
+ return ret;
}
static unsigned int try_to_freeze_tasks(int freeze_user_space)
-
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.20-git13 kernel BUG at /mnt/md0/devel/linux-git/kernel/time/tick-sched.c:168
On Sun, 2007-02-18 at 10:50 +0100, Alex Riesen wrote: > > The arch/i386/kernel/process.c part of the patch should apply to 2.6.20 > > as well. Can you check if the problem is there too ? > > It does not apply and does not look trivially hackable. > The code for cpu_idle was introduced in 2ff2d3d7 "i386: add idle notifier". Here you go. tglx Index: linux-2.6.20/arch/i386/kernel/process.c === --- linux-2.6.20.orig/arch/i386/kernel/process.c +++ linux-2.6.20/arch/i386/kernel/process.c @@ -189,6 +189,13 @@ void cpu_idle(void) play_dead(); __get_cpu_var(irq_stat).idle_timestamp = jiffies; + + local_irq_disable(); + if (local_softirq_pending() && !need_resched()) + printk(KERN_ERR + "Idle: local softirq pending: %04x\n", + local_softirq_pending()); + local_irq_enable(); idle(); } preempt_enable_no_resched(); - 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: e2b2rom_init_one(): Unable to register resource
On Sun, Feb 18, 2007 at 01:29:03PM +0200, Dan Aloni wrote: | On Sun, Feb 18, 2007 at 01:42:22PM +0300, Cyrill Gorcunov wrote: | > Hi, | > | > here is a patch attached to the mail. You may test it. Actually | > I have no 64bit machine to test it and I'm worried about the | > patch accuracy. So be carefull testing it. I sent a copy of the | > message to Andi Kleen (who is a maintainer of X86-64 port) may be | > we should wait for its answer ;) | | Thanks, I'll give it a try soon. | | BTW, wouldn't it be better just to change the type of phys and size | to u32? | | > diff --git a/drivers/mtd/maps/esb2rom.c b/drivers/mtd/maps/esb2rom.c | > index a9d808a..d63c060 100644 | > --- a/drivers/mtd/maps/esb2rom.c | > +++ b/drivers/mtd/maps/esb2rom.c | > @@ -214,6 +214,9 @@ static int __devinit esb2rom_init_one(struct pci_dev *pdev, | > | > /* reserved 0x0020 and 0x0010 */ | > window->phys -= 0x40UL; | > +#ifdef CONFIG_64BIT | > + window->phys &= 0xUL; | > +#endif | > window->size = (0xUL - window->phys) + 1UL; | > | > /* Enable writes through the rom window */ | | | -- | Dan Aloni | XIV LTD, http://www.xivstorage.com | da-x (at) monatomic.org, dan (at) xiv.co.il | Hi, actually - I don't know... I think this could be done by kernel developer specialist only (as Andi Kleen is). So lets wait until his answer ;) Nevertheless, write me if the patch resolve the problem. -- Cyrill - 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] Block layer: separate out queue-oriented ioctls
Douglas Gilbert <[EMAIL PROTECTED]> wrote: > Jens Axboe wrote: > > On Fri, Feb 16 2007, Alan Stern wrote: > >> From: James Bottomley <[EMAIL PROTECTED]> > >> > >> This patch (as854) separates out the two queue-oriented ioctls from > >> the rest of the block-layer ioctls. The idea is that they should > >> apply to any driver using a request_queue, even if the driver doesn't > >> implement a block-device interface. The prototypical example is the > >> sg driver, to which the patch adds the new interface. > >> > >> This will make it possible for cdrecord and related programs to > >> retrieve reliably the max_sectors value, regardless of whether the > >> user points it to an sr or an sg device. In particular, this will > >> resolve Bugzilla entry #7026. > > > > The block bits are fine with me, the sg calling point is a bit of a sore > > thumb (a char driver calling into block layer ioctls) though. So the > > block layer bits are certainly ok with me, if Doug acks the sg bit I'll > > merge everything up. > > > > (patch left below) > > Does this need to be in the sg driver? > > What is the hardware sector size of a SES or OSD device? > > As for the max_sector variable, wouldn't it be better > to generate a new ioctl that yielded the limit in bytes? > Making a driver variable that implicitly assumes sectors > are 512 bytes in length more visible to the user space > seems like a step in the wrong direction. This is what I did propose. I know of no SCSI device made since 1986 that has a "hardware sector size". This is really a DMA size limit in bytes and if you return the number in an unrelated multiple of a fraction, you will not be able to use the optmium max transfer size. > Alternatively the SG_GET_RESERVED_SIZE ioctl could be > modified to yield no more than max_sectors*512 . This is what I did propose 3 months ago and already 2 years ago. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation
Maybe this is a decent approach to deal with the problem. First some definitions. T is the target segment to be cleaned, S is the spare segment that valid data is written to, O are other segments that contain indirect blocks I for valid data D in T. Have two different GC mechanisms to choose between: 1. Regular GC that copies D and I into S. On average D+I should require less space than S can offer. 2. Slow GC only copies D into S. Indirect blocks get modified in-place in O. This variant requires more seeks due to writing in various O, but it guarantees that D always requires less space than S can offer. Whenever you are running out of spare segments and are in danger of the deadlock, switch to mechanism 2. Now your correctness problem is reduced to a performance problem. Jörn -- To recognize individual spam features you have to try to get into the mind of the spammer, and frankly I want to spend as little time inside the minds of spammers as possible. -- Paul Graham - 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: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug
Hi! > > > So I think tonight I'll start adding try_to_freeze() to the kernel > > > threads that > > > set PF_NOFREEZE. > > > > cool! While you are at it, let me try to enhance the freezer api's > > to incorporate the PFE_* flags. > > Here's a patch that adds try_to_freeze() to all kernel threads that didn't > call > it before. It shouldn't change the behavior of the threads in question, since > they won't be frozen because the are flagged as PF_NOFREEZE (of course > we are going to change this later). Looks ok. > Compile-tested on x86_64 with allmodconfig. > > Pavel, do you think we can remove the PF_NOFREEZE from bluetooth, > BTW? Yes... bluetooth has no reason to play with NOFREEZE. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial and tty driver
On Sun, Feb 18, 2007 at 11:52:58AM +0300, Mockern wrote: > Thank you for you respond. > > I asked this question since I have one problem with my tty driver. > It based on serial_core.c. It works well except Linux cat operation:(. > (e.g. cat < ttyS10). I thought in tty driver there is no function > for this operation and I wanted to know that maybe serial driver has it. > > Could it be the reason that cat operation in tty driver does not work > (but I can write and read from user space application!)? > Or maybe I need to implement a special function in my tty driver to support > Linux > cat operation? If you do something like "cat < ttyS10" it will work by opening the device just like a user space application --- but the shell, which is opening /dev/ttyS10, won't use any of the special flags that a user space application might use to not wait for the carrier detect line to go high, for example. I'd have to see the sources of the driver and your user space application to be sure, but one thing you should try is "stty -F /dev/ttyS10 clocal" and see if that allows "cat < /dev/ttyS10" to work. Regards, - Ted - 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.20-mm2
On Sunday, 18 February 2007 06:51, Andrew Morton wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ Two problems: 1) A showstopper with the root partition on RAID1: md: raid1 personality registered for level 1 [--snip--] md: multipath personality registered for level -4 register_blkdev: failed to get major for mdp [--snip--] VFS: Cannot open root device "md1" or unknown-block(0,0) At the moment I have no serial console attached to the box, so I had to rewrite the messages manually. 2) On HPC nx6325 I get the following 100% of the time during the resume from disk: BUG: at drivers/pci/pci.c:823 pcim_enable_device() Call Trace: [] pcim_enable_device+0x93/0xb3 [] ata_pci_device_do_resume+0x21/0x5e [] sil_pci_device_resume+0x1c/0x51 [] pci_device_resume+0x22/0x53 [] resume_device+0xca/0x131 [] dpm_resume+0x81/0xd3 [] device_resume+0x30/0x45 [] snapshot_ioctl+0x245/0x63e [] do_ioctl+0x5e/0x77 [] vfs_ioctl+0x25c/0x279 [] sys_ioctl+0x5f/0x82 [] sys_write+0x47/0x70 [] system_call+0x7e/0x83 Nevertheless, the system seems to be fully functional after the resume. [I've been observing it since 2.6.20-git10 and have reported it for a couple of times, but apparently nobody cares. :-(] Greetings, Rafael - 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: Subject: [PATCH 2.6.20 004/005] dmfe: Add support for suspend/resume
On Sunday 18 February 2007 00:52:15 Pavel Machek wrote: > Hi! > > > > Hello , I am sorry that I missed some parts of coding style. I need to > > reread it :-) > > > > There is a updated patch : > > It looks better. > > > + /* Disable Interrupt */ > > + outl (0, dev->base_addr + DCR7); > > + outl (inl(dev->base_addr + DCR5), dev->base_addr + DCR5); > > I'd kill space after outl... > > > + /* Free RX buffers */ > > + dmfe_free_rxbuffer(db); > > + > > + /* Power down device*/ > > and add space before */. > > Congratulation, you passed coding-style-police-check ;-). > Pavel > Hello, Thanks for reply, I just want to ask one question: Those patches are now merged in -mm, and I noticed that Andrew Morton after applying them did fix my bad coding style and check for CONFIG_PM=n that I didn't include Now should I resend two last patches or not ? Regards, Maxim Levitsky PS: Actualy I have planned to send those patches a little bit later , and do more checks like the coding style stuff, mailer problems, etc... but I noticed that 2.6.20 breaks link detection on my card, and I even saw report here on LKML about that, so I decided to send them now Of cource I did check them for code correctness , and I actualy used them for about a month. I tried to do as little as possible changes, and verify each line. - 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: GPL vs non-GPL device drivers
On Sun, Feb 18, 2007 at 01:26:47PM +1000, Trent Waddington wrote: > Such a strange attitude.. to go to all this effort to quote carefully > and correctly one set of people and to then total misconstrue the > words of another. > > The FSF's argument in regards to readline is that you may not > distribute readline with proprietary software linked to it. They > don't claim they "0wn" your source code. Actually, the FSF and many of its representatives, has claimed, on many occassions, that the GPL infects across dynamic linking. That is, if you write your own code that calls readline which links via a dynamically linked shared library, and perhaps even across dlopen(), they claim that the GPL applies to the code which you write. Given that the only way this could happen is via copyright law, they are basically saying that if you use the readline interface, you have created a derived work and they therefore 0wn your source code. Whether or not this would be laughed out of court or not will very much depend on the local legal precedents (and Trent Waddington has quoted some very interesting legal cases based on US court decisions, including an entertaining brief written by Eben Moglen decrying interface copyrights which on the surface seems to go against everything else the FSF has said since the Lotus case), but the kernel-mailing list isn't the place to debate how law can be applied to facts, or whether or not Eben Moglen is a hypocrite or not. So can we please stop now? I doubt anyone is going to be able to convince anyone else on this matter; people's opinions are pretty well formed by now, and until someone chooses to litigate on this specific point about whether or not the GPL (v2 or v3) can infect across a dynamic link in various jurisdictions, we're not going to settle it here. Regards, - Ted - 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/
PCI riser cards and PCI irq routing, etc
Hello, Is there some howto information available about using PCI riser cards (with multiple PCI slots) under Linux? Several incarnations exist of PCI riser cards with two PCI slots where the Device Number of one slot can be changed. How, based on what information, does Linux assign an IRQ to each card, plugged into the riser? How can one tweak/influence the irq routing? How can I make a dual riser card work so that both cards have a working interrupt? Or if stuff should work all by itself, what could be wrong? Kind regards, Udo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
> > I don't see how that is possible. mmc_block's remove routine waits for mmcqd > to > exit, so there can't be any code still alive that has a request going. (I am > also completely unable to reproduce this problem here). > > Add more printk:s do verify how the code in mmc_block executes. > This is hard to trigger problem, so I'll spare you the rather lengthy log. It happens if card timeouts and mmc_remove_host is called while mmc_register_card is still in progress (the hint was in crash dump). If I sleep before remove, it gives the mmc_register_card chance to finish/mark card as dead and everything's fine. The remove callback of mmc_block is apparently not executed in this case (probably because device has not finished registering). My proposition: lets flush the workqueue first thing in the mmc_remove_host (and make sure that nothing gets scheduled into it after this). Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html - 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: xfs internal error on a new filesystem
> > > >> Do u recommend that we switch back to reiserfs ? > > > >Not yet. > > > >> Could it be a hardware related problems ? > > > >Yes. Do you have ECC memory on your server? Have you run memtest86? > >Were there any I/O errors in the log prior to the shutdown message? > Yes, we have ECC memory. > We will try to run memtest86 as soon as possible. > There were no I/O errors in the log prior to the shutdown message. > > Btw, this is a vmware image. /vol/6 is an exported physical partition. > I've read that vmware do disk caching by default and we know xfs has problem with when disaster strikes. You definitely should disable disk caching on you side. > >Cheers, > > > >Dave. > >-- > >Dave Chinner > >Principal Engineer > >SGI Australian Software Group > > > Regards, Leon Kolchinsky - 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] input: extend EV_LED
On Sun, 18 Feb 2007, Richard Purdie wrote: > I just said that finding a way to do it generically is difficult, not > that we shouldn't do it. Very well, let's do it, then. > Even if half your functionality is exposed through the class, that half > that is standardised rather than adhoc. Having said that, you shouldn't > need any custom attributes though. Yes, that's my point. Blinking is too common, it needs to be generic (and I don't care if it is done through triggers, as long as it is generic *and* hardware-implementation-friendly, I will use it). > Right, but blinking is not an LED attribute but more of an action for > the LED so what we need is an LED blink trigger. Rather than the timer > trigger which takes a variety of options, this blink trigger could just > take an on/off value. In the absence of hardware capability, we can > emulate it. I like the idea of a simple blink trigger... If you have a 2.6.20 backport of the new LED class, I could work on it when I finish the ibm-acpi conversion to sysfs, which should take about one more week. > If a trigger/attribute appears for an LED, its behaviour needs to be the > same for all LEDs. Agreed. BTW: I need to have two leds that are the same device, different colors. The code already handles this just fine (it is NOT a multicolor led), I'd like to know how should I name the parameter? power:green and power:yellow? That should be done in a standard way as well. > The enum reflects a spectrum of loosely defined frequencies, a bit like > brightness maybe in a range 0-6. The idea is these are loose definitions > and the driver will attempt a loose match, using any hardware blinking > if available. Add the following functionality, and I think I would be happy with the interface: 1. A way for the driver to say "led access is expensive, do not enable software blink emulation" (maybe you already have this...) 2. A way for userspace to either know which ranges are hardware-emulated, or to request that only hardware emulation be used. I can live with just (1), but I think (2) would make the interface more complete. Keep in mind that whatever can be hardware-emulated is probably the default way to use that led, so it is an interesting data-point for userspace. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - 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/
freezer problems
On 02/18, Rafael J. Wysocki wrote: > > On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote: > > > > > > > > However, this means that sys_vfork() makes impossible to freeze > > > > processes > > > > until child exits/execs. Not good. > > > > > I forgot to say that we have another problem: coredumping. > > > > A thread which does do_coredump() send SIGKILL to ->mm users, and sleeps > > on ->mm->core_startup_done. Now it can't be frozen if sub-thread goes to > > refrigerator. I think this could be solved easily if we add a check to > > refrigerator() as you suggested for ->vfork_donw. > > > > > I think the real solution would be to use an interruptible completion in > > > the > > > vfork code. It was discussed some time ago and, IIRC, Ingo had an > > > experimental > > > patch that implemented it. Still, for the suspend this really is not an > > > issue > > > in practice, so it wasn't merged. > > > > It is not (afaics) so trivial to do rightly, and with this change the parent > > will be seen as TASK_INTERRUPTIBLE even without freezer in progress. > > > > A very vague idea: what if parent will do > > > > current->flags |= PF_PLEASE_CONSIDER_ME_AS_FROZEN_BUT_SET_TIF_FREEZE > > wait_for_completion(&vfork); > > try_to_freeze(); > > > > ? > > This should work, Good. So try_to_freeze_tasks() can forget about "if (!p->vfork_done)" check. This needs more thinking, of course. For example, thaw_process() should be carefull to clear TIF_FREEZE if we have the new flag set, but not PF_FROZEN. frozen() should be changed to return true if PF_NEW_FLAG && TIF_FREEZE, but it also called by refrigerator. But IF we really can do this, it will be a general solution. >but we'll need a separate process flag for it. If that's > acceptable, I can't judge. Changed the subject to have more attention from experts. > I'd call it PF_VFORK_PARENT I'd suggest not to put "VFORK" into the name. Probably we will find other usage for this flag which in fact means: "I am sleeping TASK_UNINTERRUPTIBLE at the safe place to freeze, I promise to do try_to_freeze() when I have CPU". And now another problem: exec. de_thread() sleeps in TASK_UNINTERRUPTIBLE waiting for all sub-threads to die, and we have the same "deadlock" if one of them is frozen. This is nasty. Probably we can change the ->state to TASK_INTERRUPTIBLE and add try_to_freeze(), or play with the new PF_ flag, but I am not sure it is safe to freeze() the task which is deep in the exec() path. Oleg. - 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: Which architectures need to sync vmalloc mappings between processes?
On Sat, 2007-02-17 at 21:29 -0800, Jeremy Fitzhardinge wrote: > I'm looking at making all architectures export a vmalloc_sync_all() > function, so that generic code can be sure that a particular vmalloc > mapping is present in all address spaces. I need this to implement a > function to reserve a chunk of vmalloc address space complete with > constructed pagetables, but without allocating any actual data pages. > > On i386 with PAE, this is not necessary because the kernel's mappings > are shared between all processes anyway, so it would be a no-op. > However, non-PAE i386 has a separate kernel mapping for each process, > and so needs to sync them - typically lazily on faults, but > vmalloc_sync_all exists to allow mass syncing when required. > > What other architectures would require syncing of vmalloc mappings, and > what architectures would implement it as a no-op? Er, but there are fundamental assumptions that vmalloc_sync_all() makes that simply aren't true on other architectures. Really, it's an artifact of the Intel x86 processor's inability to flush by %cr3, so we try to keep the kernel mappings alive in a process so that a sys call and return doesn't do a full TLB flush ... and thus, because we have a hidden piece of kernel in userspace, we get the HIGHMEM issues. A substantial number of other architectures do have a selective TLB flush, so a lot operate with a fully separated kernel and user space, and thus vmalloc mappings appear only in the single kernel address space and nowhere else. Could you elaborate on exactly what you think you need vmalloc_sync_all() exported for ... your explanation of a reserved vmalloc range sounds reasonable, but should in no way depend on vmalloc_sync_all(). It really sounds like this should be an arch specific function so the architectures can decide the implementation details. James - 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: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug
On 02/18, Rafael J. Wysocki wrote:
>
> On Sunday, 18 February 2007 12:32, Oleg Nesterov wrote:
> > On 02/18, Rafael J. Wysocki wrote:
> > >
> > > On Sunday, 18 February 2007 00:42, Oleg Nesterov wrote:
> > > > On 02/17, Rafael J. Wysocki wrote:
> > > > >
> > > > > On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
> > > > > >
> > > > > > static inline int is_user_space(struct task_struct *p)
> > > > > > {
> > > > > > return p->mm && !(p->flags & PF_BORROWED_MM);
> > > > > > }
> > > > > >
> > > > > > This doesn't look right. First, an exiting task has ->mm == NULL
> > > > > > after
> > > > > > do_exit()->exit_mm(). Probably not a problem. However,
> > > > > > PF_BORROWED_MM
> > > > > > check is racy without task_lock(), so we can have a false positive
> > > > > > as
> > > > > > well. Is it ok? We can freeze aio_wq prematurely.
> > > > >
> > > > > Right now aio_wq is not freezeable (PF_NOFREEZE).
> > > >
> > > > Right now yes, but we are going to change this?
> > >
> > > Well, is there any more reliable (and not racy) method of differentiating
> > > between kernel threads and user space processes?
> >
> > Not that I know of. At least, we can take task_lock() to really rule out
> > kernel threads at FREEZER_USER_SPACE stage.
>
> Something like this?
I think yes, as a first step.
In the long term, I think it would be really nice to have CLONE_KERNEL_THREAD
(filtered out in sys_clone). This also allows us to cleanup copy_process().
For example, we can then introduce CLONE_UNHASHED (currently denoted as pid==0)
and kill the ugly "int pid" copy_process's parameter.
Oleg.
> ---
> kernel/power/process.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.20-mm2/kernel/power/process.c
> ===
> --- linux-2.6.20-mm2.orig/kernel/power/process.c
> +++ linux-2.6.20-mm2/kernel/power/process.c
> @@ -8,6 +8,7 @@
>
> #undef DEBUG
>
> +#include
> #include
> #include
> #include
> @@ -92,7 +93,12 @@ static void cancel_freezing(struct task_
>
> static inline int is_user_space(struct task_struct *p)
> {
> - return p->mm && !(p->flags & PF_BORROWED_MM);
> + int ret;
> +
> + task_lock(p);
> + ret = p->mm && !(p->flags & PF_BORROWED_MM);
> + task_unlock(p);
> + return ret;
> }
>
> static unsigned int try_to_freeze_tasks(int freeze_user_space)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: > This is hard to trigger problem, so I'll spare you the rather lengthy log. > It happens if card timeouts and mmc_remove_host is called while > mmc_register_card is still in > progress (the hint was in crash dump). If I sleep before remove, it gives the > mmc_register_card > chance to finish/mark card as dead and everything's fine. > The remove callback of mmc_block is apparently not executed in this case > (probably because device > has not finished registering). Let's see, you manage to call mmc_remove_host() when a detection is pending in the workqueue? That could indeed generate new request (up until mmc_free_host() is called), but as the card is removed the mmc layer shouldn't be able to detect anything, hence mmc_block should never get involved. > > My proposition: lets flush the workqueue first thing in the mmc_remove_host > (and make sure that > nothing gets scheduled into it after this). > This is fixed in -mm. Making sure that nothing gets scheduled is the driver's responsibility. I've added checks to catch broken drivers though. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - 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: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug
On Sunday, 18 February 2007 13:14, Rafael J. Wysocki wrote:
> On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote:
> > On 02/18, Rafael J. Wysocki wrote:
> > >
> > > On Sunday, 18 February 2007 00:47, Oleg Nesterov wrote:
> > > >
> > > > However, this means that sys_vfork() makes impossible to freeze
> > > > processes
> > > > until child exits/execs. Not good.
> > >
> > > Yes, but this also is the current behavior.
> >
> > Yes, yes, I see.
> >
> > I forgot to say that we have another problem: coredumping.
> >
> > A thread which does do_coredump() send SIGKILL to ->mm users, and sleeps
> > on ->mm->core_startup_done. Now it can't be frozen if sub-thread goes to
> > refrigerator. I think this could be solved easily if we add a check to
> > refrigerator() as you suggested for ->vfork_donw.
> >
> > > I think the real solution would be to use an interruptible completion in
> > > the
> > > vfork code. It was discussed some time ago and, IIRC, Ingo had an
> > > experimental
> > > patch that implemented it. Still, for the suspend this really is not an
> > > issue
> > > in practice, so it wasn't merged.
> >
> > It is not (afaics) so trivial to do rightly, and with this change the parent
> > will be seen as TASK_INTERRUPTIBLE even without freezer in progress.
> >
> > A very vague idea: what if parent will do
> >
> > current->flags |= PF_PLEASE_CONSIDER_ME_AS_FROZEN_BUT_SET_TIF_FREEZE
> > wait_for_completion(&vfork);
> > try_to_freeze();
> >
> > ?
>
> This should work, but we'll need a separate process flag for it. If that's
> acceptable, I'd call it PF_VFORK_PARENT
Hm, what about the following patch instead?
The problem is that if the child enters the refrigeratior, we can't freeze the
parent, because it's uninterruptible, but the child knows the parent will be
uninterruptible until it exits, so the child can mark the parent as frozen.
kernel/power/process.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
Index: linux-2.6.20-mm2/kernel/power/process.c
===
--- linux-2.6.20-mm2.orig/kernel/power/process.c2007-02-18
15:43:30.0 +0100
+++ linux-2.6.20-mm2/kernel/power/process.c 2007-02-18 16:09:53.0
+0100
@@ -39,6 +39,13 @@ void refrigerator(void)
/* Hmm, should we be allowed to suspend when there are realtime
processes around? */
long save;
+
+ /* The parent is uninterruptible and will stay so until this task exits,
+* so we can mark it as frozen.
+*/
+ if (current->vfork_done)
+ frozen_process(current->parent);
+
save = current->state;
pr_debug("%s entered refrigerator\n", current->comm);
@@ -53,6 +60,9 @@ void refrigerator(void)
}
pr_debug("%s left refrigerator\n", current->comm);
current->state = save;
+
+ if (current->vfork_done && frozen(current->parent))
+ current->parent->flags &= ~PF_FROZEN;
}
static inline void freeze_process(struct task_struct *p)
@@ -117,21 +127,10 @@ static unsigned int try_to_freeze_tasks(
cancel_freezing(p);
continue;
}
- if (is_user_space(p)) {
- if (!freeze_user_space)
- continue;
-
- /* Freeze the task unless there is a vfork
-* completion pending
-*/
- if (!p->vfork_done)
- freeze_process(p);
- } else {
- if (freeze_user_space)
- continue;
+ if (is_user_space(p) == !freeze_user_space)
+ continue;
- freeze_process(p);
- }
+ freeze_process(p);
todo++;
} while_each_thread(g, p);
read_unlock(&tasklist_lock);
-
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: freezer problems
On Sunday, 18 February 2007 15:52, Oleg Nesterov wrote: > On 02/18, Rafael J. Wysocki wrote: > > > > On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote: > > > > > > > > > > However, this means that sys_vfork() makes impossible to freeze > > > > > processes > > > > > until child exits/execs. Not good. > > > > > > > I forgot to say that we have another problem: coredumping. > > > > > > A thread which does do_coredump() send SIGKILL to ->mm users, and sleeps > > > on ->mm->core_startup_done. Now it can't be frozen if sub-thread goes to > > > refrigerator. I think this could be solved easily if we add a check to > > > refrigerator() as you suggested for ->vfork_donw. > > > > > > > I think the real solution would be to use an interruptible completion > > > > in the > > > > vfork code. It was discussed some time ago and, IIRC, Ingo had an > > > > experimental > > > > patch that implemented it. Still, for the suspend this really is not > > > > an issue > > > > in practice, so it wasn't merged. > > > > > > It is not (afaics) so trivial to do rightly, and with this change the > > > parent > > > will be seen as TASK_INTERRUPTIBLE even without freezer in progress. > > > > > > A very vague idea: what if parent will do > > > > > > current->flags |= PF_PLEASE_CONSIDER_ME_AS_FROZEN_BUT_SET_TIF_FREEZE > > > wait_for_completion(&vfork); > > > try_to_freeze(); > > > > > > ? > > > > This should work, > > Good. So try_to_freeze_tasks() can forget about "if (!p->vfork_done)" check. > This needs more thinking, of course. For example, thaw_process() should be > carefull to clear TIF_FREEZE if we have the new flag set, but not PF_FROZEN. > frozen() should be changed to return true if PF_NEW_FLAG && TIF_FREEZE, but > it also called by refrigerator. > > But IF we really can do this, it will be a general solution. > > >but we'll need a separate process flag for it. If that's > > acceptable, > > I can't judge. Changed the subject to have more attention from experts. > > > I'd call it PF_VFORK_PARENT > > I'd suggest not to put "VFORK" into the name. Probably we will find other > usage for this flag which in fact means: "I am sleeping TASK_UNINTERRUPTIBLE > at the safe place to freeze, I promise to do try_to_freeze() when I have > CPU". > > And now another problem: exec. de_thread() sleeps in TASK_UNINTERRUPTIBLE > waiting for all sub-threads to die, and we have the same "deadlock" if > one of them is frozen. This is nasty. Probably we can change the ->state > to TASK_INTERRUPTIBLE and add try_to_freeze(), or play with the new PF_ > flag, but I am not sure it is safe to freeze() the task which is deep > in the exec() path. Hm, I haven't been aware of this case. Well, probably we can do something like in the patch that I've just sent: the child that enters the refrigerator should know that the parent is uninterruptible and will wait for it to exit. Thus it can either mark the parent as frozen or just exit the refrigerator without freezing itself. Greetings, Rafael - 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: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen with pata_amd
Am Samstag 17 Februar 2007 schrieb Prakash Punnoor:
> Am Samstag 17 Februar 2007 schrieb Prakash Punnoor:
> > Hi,
> >
> > I tried a cat /dev/sdb1 >/dev/null from a Sandisk Extreme III CF card
> > connected via cf to IDE adapteer to onboard ide of nforce c51. I am usinf
> > 2.6.20 on x86_64. For a few seconds it worked but then it dropped to
> > pio4:
> >
> > ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> > ata3.00: (BMDMA stat 0x65)
> > ata3.00: cmd c8/00:80:1f:7d:01/00:00:00:00:00/e0 tag 0 cdb 0x0 data 65536
> > in res 58/00:00:9e:7d:01/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
> > ata3: soft resetting port
> > ata3.00: simplex DMA is claimed by other device, disabling DMA
> > ata3.00: configured for PIO4
> > ata3: EH complete
> > SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
> > sdb: Write Protect is off
> > sdb: Mode Sense: 00 3a 00 00
> > SCSI device sdb: write cache: enabled, read cache: enabled, doesn't
> > support DPO or FUA
> >
[...]
>
> The ide driver worked better - for a short time and then this happens:
>
> hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> ide: failed opcode was: unknown
> hda: DMA disabled
I connected the cf to ide adapter to an ide to sata adapter and using this
combination on sata_nv makes no troubkes whatsoever. So what goues wrong with
pata_amd/amd ide driver? BTW, I found specs for the cf card on the sandisk
website. Perhaps someone wants to check whether the amd drivers deal
corretcly with the true ide mode implemented in the cf card?
http://www.sandisk.com/Assets/File/OEM/Manuals/ProdManCFlashv11.0.pdf
scsi 1:0:0:0: Direct-Access ATA SanDisk SDCFX-10 HDX PQ: 0 ANSI: 5
SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
SCSI device sdb: 2001888 512-byte hdwr sectors (1025 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sdb: sdb1
sd 1:0:0:0: Attached scsi removable disk sdb
sd 1:0:0:0: Attached scsi generic sg1 type 0
--
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V
pgpYZjLkm4oVW.pgp
Description: PGP signature
securityfs_create_dir strange comment
Hello list, in security/inode.c, the comment for securityfs_create_dir() reads: If securityfs is not enabled in the kernel, the value -ENODEV will be returned. It is not wise to check for this value, but rather, check for NULL or !NULL instead as to eliminate the need for #ifdef in the calling code. What is the actual callee that can return NULL - and what should module_init() of a module return when securityfs_create_dir() returns NULL? Thanks, Jan -- - 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/
OOPS
Hi, We are running the 2.6 kernel with the IOCB_CMD_EPOLL_WAIT code and the NMI watchdog is triggered: CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 0087 (2.6.9-42dbg) EIP is at __write_lock_failed+0x9/0x20 eax: c52d2d00 ebx: d9522580 ecx: 0092 edx: c52d2d00 esi: c52d2d00 edi: ebp: c044dcd4 esp: c044dcd0 nmi_watchdog_tick+0xa3/0xc1 [] default_do_nmi+0x5a/0xe8 [] do_nmi+0x40/0x4a [] nmi_stack_correct+0x1e/0x26 [] ep_poll_callback+0x18/0xaa [] __wake_up_common+0x35/0x55 [] __wake_up+0x32/0x43 [] sock_def_readable+0x7b/0x7d [] udp_queue_rcv_skb+0xfc/0x29f [] udp_rcv+0x1a2/0x41a [] ip_local_deliver_finish+0x7f/0x210 [] nf_hook_slow+0xe5/0x104 [] ip_local_deliver+0x19d/0x292 [] ip_rcv_finish+0x1e8/0x2db [] nf_hook_slow+0xe5/0x104 [] ip_rcv+0x37b/0x537 [] netif_receive_skb+0x2e8/0x36c [] e1000_clean_rx_irq+0xc6/0x630 [e1000] [] e1000_clean+0xb0/0x1a5 [e1000] [] net_rx_action+0xc2/0x1d2 [] __do_softirq+0x64/0xd2 [] do_softirq+0x53/0x5b === [] do_IRQ+0x1a5/0x1ec [] common_interrupt+0x18/0x20 Any suggestions? Thanks, Menny - 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: PCI riser cards and PCI irq routing, etc
On Sun, Feb 18, 2007 at 03:07:29PM +0100, Udo van den Heuvel wrote: > Is there some howto information available about using PCI riser cards > (with multiple PCI slots) under Linux? > Several incarnations exist of PCI riser cards with two PCI slots where > the Device Number of one slot can be changed. > How, based on what information, does Linux assign an IRQ to each card, > plugged into the riser? > How can one tweak/influence the irq routing? > How can I make a dual riser card work so that both cards have a working > interrupt? > Or if stuff should work all by itself, what could be wrong? The PCI specifications cover how pci to pci bridges should work. My understanding (which is better of verified against the specs) is: PCI interrupts (PCI INTA to INTD) are rotated for every slot by one. So slot 0, 4, 8, etc see INTA->realINTA, INTB->realINTB. INTC->realINTC, INTD->realINTD slot 1, 5, 9, etc see INTA->realINTB, INTB->realINTC. INTC->realINTD, INTD->realINTA slot 2, 6, 10, etc see INTA->realINTC, INTB->realINTD. INTC->realINTA, INTD->realINTB slot 3, 7, 11, etc see INTA->realINTD, INTB->realINTA. INTC->realINTB, INTD->realINTC The same rules apply behind a PCI bridge, so whatever INTA is on the slot with the pci bridge chip, should make to INTA on slots 0, 4, 8, etc behind the bridge, while INTB is seen as INTA on slots 1, 5, 9, etc. On a PC, the BIOS is supposed to assign interrupts to devices based on those rules, since that is how the hardware must be done according to the PCI specifications. On other platforms the firmware may or may not handle it. On ARM for example, the kernel takes care of assigning this (or it least it should). I have seen pci interrupt swizzle routines in the kernel code for an arm system which went through, looking for devices, and assigning IRQs based on their slot number, and when it found a bridge it would do a mapping past the bridge and continue assigning interrupts to devices behind the bridge. So as long as the riser board is wired according to the PCI bridge rules, then interrupts assignment should simply work. Of course if the riser card is NOT a proper pci bridge, but rather some weird device, well then it probably isn't even PCI complient and who knows how it shold be handled. Interrupts for PCI are assigned based on the 4 shared interrupts line on PCI, not really per device. A PCI device may use up to 4 interrupts if it wants to, and is supposed to always use interrupt A (as seen from it's slot) as the first interrupt. The rotating assignment of the 4 interrupts to the slots are supposed to help balance the distribution of the interrupts between devices in the system, so that although they are shared interrupts, as few devices as possible get assigned to each interrupt. On some systems some of the 4 PCI interrupts may in fact get mapped to the same interrupts if not enough are available (for example a system I work with only has two PCI interrupts available, so PCI INTA and C are the same interrupt line, and INTB and D are the same, but the system is still wired as if there were 4 interrupts, and the BIOS assigns the interrupts properly based on that, but using IRQ 11 for A and C and IRQ 10 for B and D.) -- Len Sorensen - 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: Linus' laptop and Num lock status
On Thu, 15 Feb 2007 06:34:35 -0800, H. Peter Anvin wrote: > Jean Delvare wrote: > > On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The > > BIOS RAM is mapped at 0x400 so all we need to do is to one byte from > > RAM (offset 0x497). This is how Suse's hwinfo does. > > Perhaps that's what Suse does, but the proper address is 0x417. > > 0x497 is the rarely-used LPT2 timeout counter. Still, the information printed by hwinfo is correct, I've tested it myself. Is there some publicly available documentation about the x86 BIOS RAM mapping? Thanks, -- Jean Delvare - 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/
memparse(), simple_strtoul() prototypes...
Hi, I must miss something... Looking at these prototypes unsigned long simple_strtoul(const char *cp, char **endp,unsigned int base) unsigned long long memparse (char *ptr, char **retptr) I'm really wondering why not all parameters are not all 'const'. None of these functions modify any pointer containts. And simple_strtoul() ends up doing sometghing like: if (endp) *endp = (char *)cp; Could anyone shed some light ? -- Francis - 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: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug
On 02/18, Rafael J. Wysocki wrote: > > > On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote: > > > > > > A very vague idea: what if parent will do > > > > > > current->flags |= PF_PLEASE_CONSIDER_ME_AS_FROZEN_BUT_SET_TIF_FREEZE > > > wait_for_completion(&vfork); > > > try_to_freeze(); > > > > > > ? > > Hm, what about the following patch instead? > > The problem is that if the child enters the refrigeratior, we can't freeze the > parent, because it's uninterruptible, but the child knows the parent will be > uninterruptible until it exits, so the child can mark the parent as frozen. > > --- linux-2.6.20-mm2.orig/kernel/power/process.c 2007-02-18 > 15:43:30.0 +0100 > +++ linux-2.6.20-mm2/kernel/power/process.c 2007-02-18 16:09:53.0 > +0100 > @@ -39,6 +39,13 @@ void refrigerator(void) > /* Hmm, should we be allowed to suspend when there are realtime > processes around? */ > long save; > + > + /* The parent is uninterruptible and will stay so until this task exits, > + * so we can mark it as frozen. > + */ > + if (current->vfork_done) > + frozen_process(current->parent); This is not safe. task->flags is not atomic, we can change ->flags only if we know the task won't touch it itself (ptrace, thaw_process). The parent could be interrupted, irq may play with current->flags (slab, for example). Please note that ->parent may do things like ptrace_notify() before it actually sleeps on ->vfork_done. This means that even if we could set PF_FROZEN in a safe manner, this doesn't look like a good idea. > + > + if (current->vfork_done && frozen(current->parent)) > + current->parent->flags &= ~PF_FROZEN; > } Why? If the code above works, we shouldn't take care about frozen ->parent? Oleg. - 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.20 kernel hang with USB drive and vfat doing ftruncate
Kumar Gala <[EMAIL PROTECTED]> writes:
> I'm seeing an issue with a stock 2.6.20 kernel running on an embedded
> PPC. I've got a usb flash drive plugged in and the filesystem on the
> drive is vfat. Running with 64M and no swap.
>
> If I execute a series of large (100M+) ftruncate() on the disk the
> kernel will hang and never return. It seems to be stuck in the idle
> loop().
>
> The following is the test program I'm running:
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> void usage (void)
> {
> printf ("truncate_test \n\n");
> }
>
> int main(int argc, char *argv[])
> {
> int fd, i;
> int ret = 0;
> unsigned int len;
>
> if (argc != 3) {
> printf("Invalid number of arguments\n\n");
> usage();
> exit(1);
> }
>
> fd = open(argv[1], O_CREAT|O_RDWR|O_TRUNC, S_IRWXU);
> len = strtoul(argv[2], NULL, 0);
>
> ret = ftruncate(fd, len);
>
> if (ret)
> printf ("ftruncate ret = %d %d\n", ret, errno);
>
> close(fd);
>
> return ret;
> }
>
> I usually run the following twice to get the hang state:
>
> time ./trunc_test bar 1 &
> time ./trunc_test baz 1 &
>
> I was wondering if anyone had any suggestions on what to poke at next
> to try and figure out what is going on.
Can you check /sys/block/xxx/stat or something to make sure there is
no outstanding IO request?
It seems to be no response from the lower layer...
--
OGAWA Hirofumi <[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: PCI riser cards and PCI irq routing, etc
Lennart Sorensen wrote: > On Sun, Feb 18, 2007 at 03:07:29PM +0100, Udo van den Heuvel wrote: >> How, based on what information, does Linux assign an IRQ to each card, >> plugged into the riser? >> How can one tweak/influence the irq routing? >> How can I make a dual riser card work so that both cards have a working >> interrupt? >> Or if stuff should work all by itself, what could be wrong? > > The PCI specifications cover how pci to pci bridges should work. > > My understanding (which is better of verified against the specs) is: [] > The same rules apply behind a PCI bridge, so whatever INTA is on the > slot with the pci bridge chip, should make to INTA on slots 0, 4, 8, etc > behind the bridge, while INTB is seen as INTA on slots 1, 5, 9, etc. FYI: My situation is a VIA Epia EN12000 with a TranquilPC dual PCI riser where only the Device Number can be changed. The kernel sees the two DVB cards in there as: saa7146: register extension 'budget_av'. ACPI: PCI Interrupt :00:13.0[A] -> GSI 16 (level, low) -> IRQ 16 saa7146: found saa7146 @ mem f8c3e000 (revision 1, irq 16) (0x153b,0x1157). saa7146 (0): dma buffer size 192512 DVB: registering new adapter (Terratec Cinergy 1200 DVB-T). adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff KNC1-0: MAC addr = 00:0a:ac:01:d6:87 DVB: registering frontend 0 (Philips TDA10046H DVB-T)... budget-av: ci interface initialised. ACPI: PCI Interrupt :00:14.0[A] -> GSI 17 (level, low) -> IRQ 20 saa7146: found saa7146 @ mem f8cb2000 (revision 1, irq 20) (0x153b,0x1155). saa7146 (1): dma buffer size 192512 DVB: registering new adapter (TerraTec Cinergy 1200 DVB-S). adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff sd 0:0:0:0: Attached scsi generic sg0 type 0 KNC1-1: MAC addr = 00:0a:ac:12:93:8d DVB: registering frontend 1 (ST STV0299 DVB-S)... budget-av: ci interface initialised. So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no communication with the DVB-T card (the frontend), so there is no /dev/dvb/* entry. This points to an IRQ problem. How can I find out the actual IRQ that the card is using? If it is different from what Linux thinks: how do I tell Linux? > On a PC, the BIOS is supposed to assign interrupts to devices based on > those rules, since that is how the hardware must be done according to > the PCI specifications. I set the BIOS for 'PnP OS installed'. Should I change that? > () Thanks for your response! Kind regards, Udo - 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: freezer problems
On 02/18, Rafael J. Wysocki wrote: > > On Sunday, 18 February 2007 15:52, Oleg Nesterov wrote: > > > > And now another problem: exec. de_thread() sleeps in TASK_UNINTERRUPTIBLE > > waiting for all sub-threads to die, and we have the same "deadlock" if > > one of them is frozen. This is nasty. Probably we can change the ->state > > to TASK_INTERRUPTIBLE and add try_to_freeze(), or play with the new PF_ > > flag, but I am not sure it is safe to freeze() the task which is deep > > in the exec() path. > > Hm, I haven't been aware of this case. > > Well, probably we can do something like in the patch that I've just sent: the > child that enters the refrigerator should know that the parent is > uninterruptible and will wait for it to exit. Thus it can either mark the > parent as frozen or just exit the refrigerator without freezing itself. Sub-thread could already sleep in refrigerator when another thread does exec. So we have no choice but somehow freeze the execer. But again, I don't know if it is safe to freeze it here, at de_thread() stage. It is called from load_xxx_binary(), we may hold some important locks... Oleg. - 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: Linus' laptop and Num lock status
Hi Linus, On Wed, 14 Feb 2007 11:32:34 -0800 (PST), Linus Torvalds wrote: > On Wed, 14 Feb 2007, Jean Delvare wrote: > > On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The > > BIOS RAM is mapped at 0x400 so all we need to do is to one byte from > > RAM (offset 0x497). This is how Suse's hwinfo does. > > Heh. Shows just how much I ever used DOS and BIOS. Well, I didn't know about it either before I was told about how hwinfo was able to retrieve the information. > > But maybe the first question to ask is: why is the BIOS setting lost in > > the first place? Why is the kernel resetting the led state? > > Ehh. Silly question. "Those flags, they do nothing." > > The kernel needs to know what they are in order to react correctly to > them. And since you can't read them from hardware, the only way to know > what they are (if you don't know about BIOS magic areas) is to SET THEM. > > Which is what the kernel has traditionally always done. OK, it makes sense, thanks for clarifying this point. Would it be acceptable to add some code in the kernel to read the settings from the BIOS where possible, and have the kernel write these settings rather than the default "all LEDs disabled"? The problem is that I don't know how we can know for sure whether there is BIOS RAM to read from, or not. Now that some x86-based system use EFI instead of a traditional BIOS, I guess we can't just assume that x86 or x86-64 implies there's a BIOS. -- Jean Delvare - 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] override build timestamp
Hi, On Sun, 18 Feb 2007, Olaf Hering wrote: > > On Fri, 16 Feb 2007, Olaf Hering wrote: > > > > > Pass a timestamp to kbuild via an enviroment variable. > > > > > > TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux > > > > > > This can be used when the kernel source is in a SCM and uname -v > > > is supposed to give the commit date and not the package build time. > > > > Is this really necessary? I don't really see the point of this. > > The package/kernel buildtime does not mean much, but the commit date > gives you a way to restore the source state for a given binary. This information could also be added to the version string like CONFIG_LOCALVERSION_AUTO does. OTOH rather than abusing the build date (which may not mean much, but it nevertheless has a meaning), I'd rather add the possibility to add extra information. bye, ROman - 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/
[GIT PULL] 9p patches
Linus, please pull from the 'for-linus' branch of: git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git/ for-linus This tree contains the following: Eric Van Hensbergen(1): Implement optional loose read cache Eric W. Biederman(1): Use kthread_strop instead of sending a SIGKILL. Documentation/filesystems/00-INDEX |4 ++-- Documentation/filesystems/9p.txt |4 fs/9p/fid.c|3 ++- fs/9p/mux.c|5 + fs/9p/v9fs.c |9 - fs/9p/v9fs.h |9 - fs/9p/v9fs_vfs.h |2 ++ fs/9p/vfs_addr.c |2 ++ fs/9p/vfs_dentry.c | 26 ++ fs/9p/vfs_file.c | 18 ++ fs/9p/vfs_inode.c | 20 11 files changed, 89 insertions(+), 13 deletions(-) - 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] Block layer: separate out queue-oriented ioctls
On Sat, 17 Feb 2007, Douglas Gilbert wrote: > Jens Axboe wrote: > > On Fri, Feb 16 2007, Alan Stern wrote: > >> From: James Bottomley <[EMAIL PROTECTED]> > >> > >> This patch (as854) separates out the two queue-oriented ioctls from > >> the rest of the block-layer ioctls. The idea is that they should > >> apply to any driver using a request_queue, even if the driver doesn't > >> implement a block-device interface. The prototypical example is the > >> sg driver, to which the patch adds the new interface. > >> > >> This will make it possible for cdrecord and related programs to > >> retrieve reliably the max_sectors value, regardless of whether the > >> user points it to an sr or an sg device. In particular, this will > >> resolve Bugzilla entry #7026. > > > > The block bits are fine with me, the sg calling point is a bit of a sore > > thumb (a char driver calling into block layer ioctls) though. So the > > block layer bits are certainly ok with me, if Doug acks the sg bit I'll > > merge everything up. > > > > (patch left below) > > Does this need to be in the sg driver? Something like it does. Otherwise cdrecord (or any other sg user) has no way to retrieve the max_sectors value for sg devices. > What is the hardware sector size of a SES or OSD device? I have no idea, and I don't see why it is relevant. (I don't even know what "SES" and "OSD" refer to.) > As for the max_sector variable, wouldn't it be better > to generate a new ioctl that yielded the limit in bytes? Maybe. I wouldn't mind doing it that way. But we would have to leave in the old ioctl, and we probably would still want it to be usable for sg devices. Not to mention that it would be silly to have two ioctls which always return exactly the same values except for a factor of 512. > Making a driver variable that implicitly assumes sectors > are 512 bytes in length more visible to the user space > seems like a step in the wrong direction. > > Alternatively the SG_GET_RESERVED_SIZE ioctl could be > modified to yield no more than max_sectors*512 . There should be one single ioctl which can be applied uniformly to all CD-type devices (in fact, to all devices using a request_queue) to learn max_sectors. This rules out using SG_GET_RESERVED_SIZE. Furthermore, if you changed SG_GET_RESERVED_SIZE in this way you would only increase the confusion. The reserved size isn't directly related to the maximum allowed DMA length, and there's no point pretending it is. What if it turns out that the reserved size is smaller than max_sectors? Then you'd force user programs to do I/O in chunks that were smaller than necessary. > >> + /* block ioctls first */ > > Why first?? I don't know -- James will have to answer. I don't see that it makes any real difference; the new code can easily be moved to the end. > That would allow the block layer to overtake any currently > defined and working sg ioctl. > Surely, if it was put in, it should be in the default case. Would the patch be okay with you if I rework it to put the new ioctls under the default case in sg? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386 make NMI use PERFCTR1 for architectural perfmon
On Saturday 17 February 2007 17:06, Stephane Eranian wrote: > Hello, > > This patch against 2.6.20 Please always submit against mainline: patching file arch/i386/kernel/nmi.c Hunk #1 FAILED at 288. Hunk #2 succeeded at 740 (offset 55 lines). Hunk #3 succeeded at 1017 with fuzz 1 (offset 59 lines). 1 out of 3 hunks FAILED -- rejects in file arch/i386/kernel/nmi.c Patch patches/i386-make-nmi-use-perfctr1-for-architectural-perfmon does not apply (enforce with -f) -Andi - 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.20-ck1
Hi Con, Con Kolivas wrote: Would some -ck user on the mailing list like to perform a set of interbench benchmarks? They're pretty straight forward to do; see: Here are my results for AMD 3200+ (2.2Ghz, uniprocessor), 1gb RAM, 10,000RPM SATA drive after clean boots into runlevel 1. 2.6.19-ck1 data are included at the bottom. Using 1116777 loops per ms, running every load for 30 seconds Benchmarking kernel 2.6.20 at datestamp 200702172323 --- Benchmarking simulated cpu of Audio in the presence of simulated --- LoadLatency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0.003 +/- 0.003140.005 100100 Video 0.002 +/- 0.002540.006 100100 X 0.996 +/- 2.57 10 100100 Burn 0.002 +/- 0.002410.011 100100 Write 0.053 +/- 0.6 10 100100 Read 0.009 +/- 0.0117 0.114 100100 Compile 0.023 +/- 0.368 9.01 100100 Memload 0.013 +/- 0.0578 0.948 100100 --- Benchmarking simulated cpu of Video in the presence of simulated --- LoadLatency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0.002 +/- 0.002610.004 100100 X 3.5 +/- 8.3826.7 100 86.7 Burn 0.002 +/- 0.002350.006 100100 Write 0.072 +/- 1.1826.7 100 99.7 Read 0.007 +/- 0.008910.063 100100 Compile 0.031 +/- 0.677 21.7 100 99.9 Memload 0.014 +/- 0.0688 1.57 100100 --- Benchmarking simulated cpu of X in the presence of simulated --- LoadLatency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0.026 +/- 0.231 298.7 98 Video 10.8 +/- 23.4 6937.7 30.2 Burn 0.026 +/- 0.231 298.7 98 Write 0.543 +/- 3.54 5589.6 86.8 Read 0.026 +/- 0.231 298.7 98 Compile 1.8 +/- 23.7 40580.5 77.9 Memload 0.029 +/- 0.238 298.7 97.7 --- Benchmarking simulated cpu of Gaming in the presence of simulated --- LoadLatency +/- SD (ms) Max Latency % Desired CPU None 0 +/- 0 0 100 Video 63.2 +/- 64.866.561.3 X 100 +/- 213 139249.9 Burn349 +/- 375 40022.3 Write 46.4 +/- 112 89168.3 Read 8.45 +/- 8.6312.292.2 Compile 437 +/- 505 113818.6 Memload15.4 +/- 23.8 15986.7 Using 1116777 loops per ms, running every load for 30 seconds Benchmarking kernel 2.6.20-ck1 at datestamp 200702180758 --- Benchmarking simulated cpu of Audio in the presence of simulated --- LoadLatency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0.002 +/- 0.002420.005 100100 Video 0.002 +/- 0.002410.003 100100 X 0.206 +/- 0.98 7 100100 Burn 0.002 +/- 0.002380.003 100100 Write 0.014 +/- 0.204 5 100100 Read 0.007 +/- 0.008470.062 100100 Compile 0.007 +/- 0.007830.062 100100 Memload 0.036 +/- 0.254 5 100100 --- Benchmarking simulated cpu of Video in the presence of simulated --- LoadLatency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0.002 +/- 0.002470.018 100100 X 0.236 +/- 1.1516.7 100 99.9 Burn 0.002 +/- 0.002520.012 100100 Write 0.006 +/- 0.041 1 100100 Read 0.007 +/- 0.0168 0.486 100100 Compile 0.007 +/- 0.0278 0.643 100100 Memload 0.031 +/- 0.247 5 100100 --- Benchmarking simulated cpu of X in the presence of simulated --- LoadLatency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0.049 +/- 0.465 798.7 97.7 Video 14.1 +/- 26.3 6836.2 26.7 Burn 0.016 +/- 0.173 299.3 98.7 Write 0.413 +/- 1.7 1090.6 87.2 Read 0.013 +/- 0.141 2 100 99 Compile 0.116 +/- 0.794 896.8 95.4 Memload 0.292 +/- 2.51 3697.4 95
Re: e2b2rom_init_one(): Unable to register resource
[adding mtd maintainer]
On Sunday 18 February 2007 11:42, Cyrill Gorcunov wrote:
> On Sat, Feb 17, 2007 at 11:29:19PM +0200, Dan Aloni wrote:
> | Hello,
> |
> | I'm running the x86_64 arch of Linux 2.6.20 on a Supermicro X6DH8-XG2
> | board and I got this during boot:
> |
> | [248660.950695] device id = 2440
> | [248660.950699] device id = 2480
> | [248660.950703] device id = 24c0
> | [248660.950706] device id = 24d0
> | [248660.950709] matched device = 24d0
> | [248660.950712] matched device id 24d0
> | [248660.950716] pci_read_config_byte : 4
> | [248660.950723] esb2rom: esb2rom_init_one(): Unable to register resource
> | 0xffc0-0x - kernel bug?
> | [248660.950729] esb2rom: ioremap(ffc0, 10040) failed
> | [248660.956859] retVal = -19
> |
> | Looks like some kind of a 64-bit portability bug...
> |
> | --
> | Dan Aloni
> | XIV LTD, http://www.xivstorage.com
> | da-x (at) monatomic.org, dan (at) xiv.co.il
> | -
> | 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/
> |
>
> Hi,
>
> here is a patch attached to the mail. You may test it. Actually
> I have no 64bit machine to test it and I'm worried about the
> patch accuracy. So be carefull testing it. I sent a copy of the
> message to Andi Kleen (who is a maintainer of X86-64 port) may be
> we should wait for its answer ;)
Making window->phys u32 seems like a cleaner fix.
(untested)
-Andi
Fix 64bit arithmetic bug in esb2rom.c
Index: linux/drivers/mtd/maps/esb2rom.c
===
--- linux.orig/drivers/mtd/maps/esb2rom.c
+++ linux/drivers/mtd/maps/esb2rom.c
@@ -95,8 +95,8 @@
struct esb2rom_window {
void __iomem* virt;
- unsigned long phys;
- unsigned long size;
+ u32 phys;
+ u32 size;
struct list_head maps;
struct resource rsrc;
struct pci_dev *pdev;
-
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: kbuild question
Hi, On Fri, 16 Feb 2007, Kumar Gala wrote: > > Could you please be more specific about the problem you're trying to > > solve, instead of how you're trying to solve it? > > A real example would help a lot to understand the actual problem. > > Sure, on powerpc for some of the embedded sub-architectures you can only > select a single board to build for. For a lot of people this is sufficient, > however we are moving towards a world where you can easily build in support > for multiple boards into a single kernel. > > I'd like to have it such that if I'm only building support for one board > (CONFIG_ONLY_HAVE_ONE, not going to call it that, but for this discussion its > sufficient), you get a choice menu from Kconfig enforcing the ability to only > select one board. However if !CONFIG_ONLY_HAVE_ONE than you can select > multiple boards to build into your kernel. > > if CONFIG_ONLY_HAVE_ONE is set we can optimize out the runtime checks that get > added for handling the multiple board case. On m68k we have the same problem, but what I'm what I'm considering is to add a new mode for choice groups - at least one must be selected and kconfig generates the extra information if only one is selected. bye, Roman - 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 PULL] hwmon updates for 2.6.21
Linus, Please don't forget to pull the hwmon subsystem updates for Linux 2.6.21 from: git://jdelvare.pck.nerim.net/jdelvare-2.6 hwmon-for-linus The merge window is closing soon and I'd like these changes to be in 2.6.21-rc1. Thanks, -- Jean Delvare - 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: Using sched_clock for mmio-trace
On Sat, Feb 17, 2007 at 04:19:58PM +0100, Thomas Gleixner wrote: > On Sat, 2007-02-17 at 15:56 +0100, Andi Kleen wrote: > > > This is one of the reasons why we don't just use good old > > > do_gettimeofday(), since it takes locks and can lead to lock recursion > > > if parts of itself are probed. > > > > do_gettimeofday doesn't take locks. > > > > Only restriction is that you can't single step it with long > > pauses between instructions. > > Err, it uses read side of xtime lock, so you can not call it from a > place which write locks xtime lock. Err, you can -- seqlocks never deadlock. The only thing that doesn't work is to single step with long enough pauses with interrupts on inbetween that the sequence numbers increase: you get a livelock then. -Andi - 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: Linus' laptop and Num lock status
Jean Delvare wrote: On Thu, 15 Feb 2007 06:34:35 -0800, H. Peter Anvin wrote: Jean Delvare wrote: On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The BIOS RAM is mapped at 0x400 so all we need to do is to one byte from RAM (offset 0x497). This is how Suse's hwinfo does. Perhaps that's what Suse does, but the proper address is 0x417. 0x497 is the rarely-used LPT2 timeout counter. Still, the information printed by hwinfo is correct, I've tested it myself. Is there some publicly available documentation about the x86 BIOS RAM mapping? Google for Ralf Brown's Interrupt List. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
Add two new maturity levels of DEPRECATED and OBSOLETE to the kbuild structure. Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> --- one more time, i'll see if i can get this into the main tree, since previous attempts just seem to disappear into the void, even though several people seemed to think it was a good idea. diff --git a/init/Kconfig b/init/Kconfig index a3f83e2..acc0052 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -29,9 +29,10 @@ config EXPERIMENTAL , and in the kernel source). - This option will also make obsoleted drivers available. These are - drivers that have been replaced by something else, and/or are - scheduled to be removed in a future kernel release. + At the moment, this option also makes obsolete drivers available, + but such drivers really should be removed from the EXPERIMENTAL + category and added to either DEPRECATED or OBSOLETE, depending + on their status. Unless you intend to help test and develop a feature or driver that falls into this category, or you have a situation that requires @@ -40,6 +41,29 @@ config EXPERIMENTAL you say Y here, you will be offered the choice of using features or drivers that are currently considered to be in the alpha-test phase. +config DEPRECATED + bool "Prompt for deprecated code/drivers" + default y + ---help--- + Code that is tagged as "deprecated" is officially still available + for use but will typically have already been scheduled for removal + at some point, so it's in your best interests to start looking for + an alternative. + + Check the file Documentation/feature-removal-schedule.txt to see + if a particular feature has an official scheduled removal date. + +config OBSOLETE + bool "Prompt for obsolete code/drivers" + default n + ---help--- + Code that is tagged as "obsolete" is officially no longer supported + and shouldn't play a part in any normal build, but those features + might still be available if you absolutely need access to them. + + You are *strongly* discouraged from continuing to depend on + obsolete code on an ongoing, long-term basis. + config BROKEN bool -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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: e2b2rom_init_one(): Unable to register resource
On Sun, Feb 18, 2007 at 06:13:38PM +0100, Andi Kleen wrote: > [adding mtd maintainer] > > On Sunday 18 February 2007 11:42, Cyrill Gorcunov wrote: > > On Sat, Feb 17, 2007 at 11:29:19PM +0200, Dan Aloni wrote: > > | Hello, > > | > > | I'm running the x86_64 arch of Linux 2.6.20 on a Supermicro X6DH8-XG2 > > | board and I got this during boot: > > | > > | [248660.950695] device id = 2440 > > | [248660.950699] device id = 2480 > > | [248660.950703] device id = 24c0 > > | [248660.950706] device id = 24d0 > > | [248660.950709] matched device = 24d0 > > | [248660.950712] matched device id 24d0 > > | [248660.950716] pci_read_config_byte : 4 > > | [248660.950723] esb2rom: esb2rom_init_one(): Unable to register resource > > | 0xffc0-0x - kernel bug? > > | [248660.950729] esb2rom: ioremap(ffc0, 10040) failed > > | [248660.956859] retVal = -19 > > | > > | Looks like some kind of a 64-bit portability bug... [...] > > Making window->phys u32 seems like a cleaner fix. > (untested) With this fix it still looks somewhat broken: [889227.698252] device id = 2440 [889227.698261] device id = 2480 [889227.698264] device id = 24c0 [889227.698268] device id = 24d0 [889227.698271] matched device = 24d0 [889227.698274] matched device id 24d0 [889227.698280] pci_read_config_byte : 4 [889227.698289] esb2rom: esb2rom_init_one(): Unable to register resource 0xffc0-0x - kernel bug? [889227.700676] CFI: Found no esb2rom @ffc0 device at location zero [889227.717995] JEDEC: Found no esb2rom @ffc0 device at location zero [889227.720811] CFI: Found no esb2rom @ffc0 device at location zero [889227.747009] JEDEC: Found no esb2rom @ffc0 device at location zero [889227.748692] CFI: Found no esb2rom @ffc0 device at location zero [889227.763736] JEDEC: Found no esb2rom @ffc0 device at location zero [889227.765438] CFI: Found no esb2rom @ffc1 device at location zero [889227.782755] JEDEC: Found no esb2rom @ffc1 device at location zero [889227.785566] CFI: Found no esb2rom @ffc1 device at location zero [889227.810647] JEDEC: Found no esb2rom @ffc1 device at location zero [889227.812330] CFI: Found no esb2rom @ffc1 device at location zero [889227.827378] JEDEC: Found no esb2rom @ffc1 device at location zero [889227.829081] CFI: Found no esb2rom @ffc2 device at location zero [889227.846390] JEDEC: Found no esb2rom @ffc2 device at location zero [889227.849202] CFI: Found no esb2rom @ffc2 device at location zero [889227.874279] JEDEC: Found no esb2rom @ffc2 device at location zero [889227.875961] CFI: Found no esb2rom @ffc2 device at location zero [889227.891005] JEDEC: Found no esb2rom @ffc2 device at location zero [889227.892710] CFI: Found no esb2rom @ffc3 device at location zero [889227.910022] JEDEC: Found no esb2rom @ffc3 device at location zero [889227.912835] CFI: Found no esb2rom @ffc3 device at location zero [889227.937915] JEDEC: Found no esb2rom @ffc3 device at location zero [889227.939594] CFI: Found no esb2rom @ffc3 device at location zero [889227.954636] JEDEC: Found no esb2rom @ffc3 device at location zero [889227.956339] CFI: Found no esb2rom @ffc4 device at location zero [889227.973647] JEDEC: Found no esb2rom @ffc4 device at location zero [889227.976461] CFI: Found no esb2rom @ffc4 device at location zero [889228.001560] JEDEC: Found no esb2rom @ffc4 device at location zero [889228.003243] CFI: Found no esb2rom @ffc4 device at location zero [889228.018296] JEDEC: Found no esb2rom @ffc4 device at location zero [889228.02] CFI: Found no esb2rom @ffc5 device at location zero [889228.037315] JEDEC: Found no esb2rom @ffc5 device at location zero [889228.040129] CFI: Found no esb2rom @ffc5 device at location zero [889228.065218] JEDEC: Found no esb2rom @ffc5 device at location zero [889228.066899] CFI: Found no esb2rom @ffc5 device at location zero [889228.081943] JEDEC: Found no esb2rom @ffc5 device at location zero [889228.083640] CFI: Found no esb2rom @ffc6 device at location zero [889228.100949] JEDEC: Found no esb2rom @ffc6 device at location zero [889228.103760] CFI: Found no esb2rom @ffc6 device at location zero [889228.128850] JEDEC: Found no esb2rom @ffc6 device at location zero [889228.130529] CFI: Found no esb2rom @ffc6 device at location zero [889228.145575] JEDEC: Found no esb2rom @ffc6 device at location zero [889228.147275] CFI: Found no esb2rom @ffc7 device at location zero [889228.164593] JEDEC: Found no esb2rom @ffc7 device at location zero [889228.167398] CFI: Found no esb2rom @ffc7 device at location zero [889228.192491] JEDEC: Found no esb2rom @ffc7 device at location zero [889228.194173] CFI: Found no esb2rom @ffc7 device at location zero [889228.209767] JEDEC: Found no esb2rom @ffc7 device at location zero [889228.211466] CFI: Found no esb2rom @ffc8 device at lo
Re: 2.6.20-mm2: Oops in generic_make_request
On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: > Le 18.02.2007 06:51, Andrew Morton a écrit : > >Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > >Will appear later at > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > Hello, I've got a fully reproducible Oops. I just have to boot to > runlevel 2 and wait less than one minute. Maybe this oops is related too? Can't yet tell if it's easily reproducible, this is on a JFS filesystem. BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: c02206aa *pde = Oops: [#1] PREEMPT last sysfs file: /devices/pci:00/:00:00.0/class CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010297 (2.6.20-mm2-1 #1) EIP is at __make_request+0x13a/0x390 eax: ebx: ecx: 042b0dd8 edx: 00010485 esi: c5f8cea0 edi: cfd587f8 ebp: c653dadc esp: c653dabc ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process sh (pid: 4549, ti=c653c000 task=ccca2090 task.ti=c653c000) Stack: c137eae8 0001 cfd587e4 c5f8cea0 c5f893e4 c137eae8 c5f8cea0 0008 c653db28 c021e0ca cfa3ffa0 cee6a2e0 cfa3ffa0 0008 0100 00011250 cfedaf60 c653db10 0206 c653db18 c014a31e c653db48 Call Trace: [] show_trace_log_lvl+0x1a/0x30 [] show_stack_log_lvl+0xa9/0xd0 [] show_registers+0x206/0x350 [] die+0x10e/0x210 [] do_page_fault+0x2d2/0x600 [] error_code+0x74/0x7c [] generic_make_request+0x15a/0x200 [] submit_bio+0x58/0xe0 [] metapage_writepage+0x18f/0x1b0 [] __writepage+0xb/0x30 [] write_cache_pages+0x22f/0x300 [] generic_writepages+0x23/0x30 [] do_writepages+0x5c/0x60 [] __filemap_fdatawrite_range+0x67/0x80 [] filemap_flush+0x25/0x30 [] lmLogSync+0x19d/0x230 [] lmLog+0x5e/0x190 [] txCommit+0x8c0/0x1010 [] jfs_create+0x324/0x370 [] vfs_create+0xaf/0x100 [] open_namei+0x58c/0x640 [] do_filp_open+0x2c/0x50 [] do_sys_open+0x47/0xe0 [] sys_open+0x1c/0x20 [] syscall_call+0x7/0xb === Code: 5d c3 8b 58 18 8b 43 04 0f 18 00 90 8b 7d e8 83 c7 14 39 fb 75 2 4 e9 2d ff ff ff 8d b6 00 00 00 00 48 0f 84 d9 00 00 00 8b 5b 04 <8b> 43 04 0f 18 00 90 39 fb 0f 84 0e ff ff ff 89 f2 89 d8 e8 2e EIP: [] __make_request+0x13a/0x390 SS:ESP 0068:c653dabc -- mattia :wq! - 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: Linus' laptop and Num lock status
On Sun, 18 Feb 2007 17:04:01 +0100 Jean Delvare wrote: > On Thu, 15 Feb 2007 06:34:35 -0800, H. Peter Anvin wrote: > > Jean Delvare wrote: > > > On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The > > > BIOS RAM is mapped at 0x400 so all we need to do is to one byte from > > > RAM (offset 0x497). This is how Suse's hwinfo does. > > > > Perhaps that's what Suse does, but the proper address is 0x417. > > > > 0x497 is the rarely-used LPT2 timeout counter. > > Still, the information printed by hwinfo is correct, I've tested it > myself. Is there some publicly available documentation about the x86 > BIOS RAM mapping? Hilo, 0x40:0x17 is called "keyboard control" and 0x40:0x97 is called "keyboard LED flags" in the IBM Personal System/2 and Personal Computer BIOS Interface Technical Reference, Section 3: Data Areas and ROM Tables. /bios data areas tables/ :: http://heim.ifi.uio.no/~stanisls/helppc/bios_data_area.html http://heim.ifi.uio.no/~stanisls/helppc/kb_flags.html --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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: Which architectures need to sync vmalloc mappings between processes?
> On i386 with PAE, this is not necessary because the kernel's mappings > are shared between all processes anyway, so it would be a no-op. > However, non-PAE i386 has a separate kernel mapping for each process, > and so needs to sync them - typically lazily on faults, but > vmalloc_sync_all exists to allow mass syncing when required. The only case that needs it right now on x86 is NMI handlers in modules to avoid early IRETs that could cause NMI recursion. That's a very obscure architecture specific quirk and I wouldn't expect any other architecture to suffer from this. -Andi - 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/
[GIT PATCH] final SCSI updates for 2.6.20
These represent the final updates, after which we'll move over into separated fixes for post 2.6.21 and bug fixes for rc candidates mode. The patches are available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git The short changelog is: Alan Stern (3): SCSI core: better initialization for sdev->scsi_level scsi_proc.c: display sdev->scsi_level correctly scsi_scan.c: handle bad inquiry responses FUJITA Tomonori (1): tgt: fix the user/kernel ring buffer interface James Bottomley (1): aic94xx: tie driver to the major number of the sequencer firmware Linas Vepstas (1): lpfc: add PCI error recovery support peter fuerst (2): sgiwd93: interfacing to wd33c93 wd33c93: Fast SCSI with WD33C93B Richard Knutsson (1): megaraid: pci_module_init to pci_register_driver Rolf Eike Beer (2): scsi_transport.h should include scsi_device.h aic79xx: remove extra newline from info message Sumant Patro (5): megaraid_sas: update version and author info megaraid_sas: return sync cache call with success megaraid_sas: replace pci_alloc_consitent with dma_alloc_coherent in ioctl path megaraid_sas: add bios_param in scsi_host_template megaraid_sas: do not process cmds if hw_crit_error is set and the diffstat drivers/scsi/aic7xxx/aic79xx_osm.c |1 drivers/scsi/aic94xx/aic94xx_seq.c | 13 + drivers/scsi/aic94xx/aic94xx_seq.h |1 drivers/scsi/lpfc/lpfc_init.c| 97 ++ drivers/scsi/lpfc/lpfc_sli.c | 12 + drivers/scsi/megaraid.c |2 drivers/scsi/megaraid/megaraid_sas.c | 90 - drivers/scsi/megaraid/megaraid_sas.h |6 drivers/scsi/scsi_proc.c |5 drivers/scsi/scsi_scan.c | 14 + drivers/scsi/scsi_sysfs.c|2 drivers/scsi/scsi_tgt_if.c |8 drivers/scsi/sgiwd93.c |5 drivers/scsi/wd33c93.c | 321 ++- drivers/scsi/wd33c93.h |6 include/scsi/scsi_tgt_if.h |3 include/scsi/scsi_transport.h|1 17 files changed, 481 insertions(+), 106 deletions(-) James - 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: [lm-sensors] Could the k8temp driver be interfering with ACPI?
Hi Chuck, On Fri, 16 Feb 2007 14:31:44 -0500, Chuck Ebbert wrote: > Andi Kleen wrote: > > Chuck Ebbert wrote: > > > So, could ACPI and the k8temp driver be at odds? > > > > Yes, there is no locking between ACPI and Linux drivers for register access. > > e.g. if there is a indexed register both try to access (and temperature > > sensors tend to use these things) they can race and get corrupted data. > > I blacklisted the k8temp driver and everything looks OK now. You could blacklist the ACPI "thermal" module instead. If you're interested in monitoring your CPU temperature, k8temp is IMHO more convenient to use than ACPI, as it interfaces properly with libsensors and all hardware monitoring user interfaces. -- Jean Delvare - 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: [lm-sensors] Could the k8temp driver be interfering with ACPI?
On Sat, 17 Feb 2007 13:14:50 -0500, Chuck Ebbert wrote: > Well I had an idea after looking at k8temp -- why not make it default to > doing only reads from the sensor? You'd only get information from whatever > core/sensor combination that ACPI had last used, but it would be safe. ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI doesn't conflict with only k8temp, but with virtually all hardware monitoring drivers, all I2C/SMBus drivers, and probably other types of drivers too. We just can't restrict or blacklist all these drivers because ACPI misbehaves. -- Jean Delvare - 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: Linus' laptop and Num lock status
On Sun, 18 Feb 2007 09:32:15 -0800 H. Peter Anvin wrote: > Jean Delvare wrote: > > On Thu, 15 Feb 2007 06:34:35 -0800, H. Peter Anvin wrote: > >> Jean Delvare wrote: > >>> On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The > >>> BIOS RAM is mapped at 0x400 so all we need to do is to one byte from > >>> RAM (offset 0x497). This is how Suse's hwinfo does. > >> Perhaps that's what Suse does, but the proper address is 0x417. > >> > >> 0x497 is the rarely-used LPT2 timeout counter. > > > > Still, the information printed by hwinfo is correct, I've tested it > > myself. Is there some publicly available documentation about the x86 > > BIOS RAM mapping? > > > > Google for Ralf Brown's Interrupt List. (Ralph) I didn't find the BIOS data areas/tables in Ralph's web pages... --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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.20-mm2
Andrew Morton napisał(a):
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.20-mm2/
>
Slab corruption + oops yablb (yet another block layer bug)
Slab corruption: start=f3b8f654, len=176
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [](mempool_free_slab+0xe/0x10)
060: 6b 6b 6b 6b 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Prev obj: start=f3b8f598, len=176
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [](mempool_free_slab+0xe/0x10)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Next obj: start=f3b8f710, len=176
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [](mempool_free_slab+0xe/0x10)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
0xc0160f39 is in mempool_free_slab (/mnt/md0/devel/linux-mm/mm/mempool.c:295).
290
291 void mempool_free_slab(void *element, void *pool_data)
292 {
293 struct kmem_cache *mem = pool_data;
294 kmem_cache_free(mem, element);
295 }
296 EXPORT_SYMBOL(mempool_free_slab);
297
298 /*
299 * A commonly used alloc and free fn that kmalloc/kfrees the amount of
memory
quilt patches mm/mempool.c
patches/origin.patch
It's time to test 2.6.20-git14 with LTP.
BUG: unable to handle kernel paging request at virtual address 6b6b6b8f
printing eip:
c01f4618
*pde =
Oops: [#1]
PREEMPT SMP
last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd
nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT
nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter
ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram evdev
snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer intel_agp 8139too agpgart skge snd i2c_i801 mii soundcore sk98lin
snd_page_alloc ide_cd cdrom rtc unix
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010292 (2.6.20-mm2 #18)
EIP is at ll_back_merge_fn+0x9d/0x1ba
eax: 6b6b6b6b ebx: f5e6a2a8 ecx: 1000 edx: 0001
esi: f7cc1a14 edi: f5e6a2a8 ebp: ee7ebb34 esp: ee7ebb18
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process doio (pid: 11602, ti=ee7ea000 task=f339a070 task.ti=ee7ea000)
Stack: f306d394 1000 f7cb2e54 ee7ebb34 f5e6a2a8 f306d394 f7cc1a14 ee7ebb5c
c01f622f c020fad7 f5e6a2a8 f306d394 f306d394 ee7ebb5c f5e6a2a8 f7cc1a14
f306d394 ee7ebb94 c01f7a74 ee7ebb8c c013ea3c f339a5e8 0002 f339a070
Call Trace:
[] show_trace_log_lvl+0x1a/0x2f
[] show_stack_log_lvl+0x9d/0xac
[] show_registers+0x1ed/0x34c
[] die+0x11d/0x234
[] do_page_fault+0x47c/0x55b
[] error_code+0x7c/0x84
[] bio_attempt_back_merge+0x40/0xe3
[] __make_request+0xe1/0x32e
[] generic_make_request+0x2e1/0x30f
[] submit_bio+0x132/0x13a
[] submit_bh+0xf6/0x113
[] __block_write_full_page+0x242/0x35c
[] block_write_full_page+0xc9/0xd1
[] ext3_ordered_writepage+0x100/0x1b1
[] __writepage+0xb/0x25
[] write_cache_pages+0x19d/0x2b4
[] generic_writepages+0x22/0x2a
[] do_writepages+0x36/0x48
[] __filemap_fdatawrite_range+0x5b/0x67
[] filemap_fdatawrite_range+0x22/0x29
[] sync_page_range+0x8c/0x107
[] generic_file_aio_write+0xbf/0xdb
[] ext3_file_write+0x27/0x99
[] do_sync_write+0xd7/0x114
[] vfs_write+0xd1/0x15a
[] sys_write+0x3d/0x72
[] syscall_call+0x7/0xb
===
Code: ff 8b 45 e4 8b 50 0c 83 f2 08 c1 ea 03 83 e2 01 b8 20 e1 43 c0 e8 e5 bb
01 00 85 c0 74 0a 8b 55 e4 89 f0 e8 63 f4 ff ff 8b 47 38 <8b> 50 24 89 55 e8 8b
4d e4 8b 49 20 89 4d ec 0f b7 48 14 6b c9
EIP: [] ll_back_merge_fn+0x9d/0x1ba SS:ESP 0068:ee7ebb18
0xc01f4618 is in ll_back_merge_fn
(/mnt/md0/devel/linux-mm/block/ll_rw_blk.c:1421).
1416}
1417if (unlikely(!bio_flagged(req->biotail, BIO_SEG_VALID)))
1418blk_recount_segments(q, req->biotail);
1419if (unlikely(!bio_flagged(bio, BIO_SEG_VALID)))
1420blk_recount_segments(q, bio);
1421len = req->biotail->bi_hw_back_size + bio->bi_hw_front_size;
1422if (BIOVEC_VIRT_MERGEABLE(__BVEC_END(req->biotail),
__BVEC_START(bio)) &&
1423!BIOVEC_VIRT_OVERSIZE(len)) {
1424int mergeable = ll_new_mergeable(q, req, bio);
1425
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20-mm2/mm-config
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
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/
dirty balancing deadlock
I was testing the new fuse shared writable mmap support, and finding that bash-shared-mapping deadlocks (which isn't so strange ;). What is more strange is that this is not an OOM situation at all, with plenty of free and cached pages. A little more investigation shows that a similar deadlock happens reliably with bash-shared-mapping on a loopback mount, even if only half the total memory is used. The cause is slightly different in the two cases: - loopback mount: allocation by the underlying filesystem is stalled on throttle_vm_writeout() - fuse-loop: page dirtying on the underlying filesystem is stalled on balance_dirty_pages() In both cases the underlying fs is totally innocent, with no dirty/writback pages, yet it's waiting for the global dirty+writeback to go below the threshold, which obviously won't, until the allocation/dirtying succeeds. I'm not quite sure what the solution is, and asking for thoughts. Ideas: - per filesystem dirty counters. If filesystem is clean (or dirty is below some minimum), then balance_dirty_pages() should no wait any more - throttle_vm_writeout() was meant to throttle swapping, no? So in that case there should be a separate swap-writback counter Thanks, Miklos - 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] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
Hi, Would it be possible to get this patch merged (or at least DEPRECATED part of it)? I think that the patch is useful and that the distinction between DEPRECATED and OBSOLETE options is quite clear: * DEPRECATED == new better code is available, old code scheduled for removal * OBSOLETE == no replacement yet but the code is broken by design and unreliable, not scheduled for removal yet (BTW Robert, I think CONFIG_OBSOLETE should also be "default y", at least initially) I would like to start using CONFIG_DEPRECATED and CONFIG_OBSOLETE for some IDE config config options/features (not drivers) in the future. Thanks, Bart On Sunday 18 February 2007 18:06, Robert P. J. Day wrote: > > Add two new maturity levels of DEPRECATED and OBSOLETE to the kbuild > structure. > > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> > > --- > > one more time, i'll see if i can get this into the main tree, since > previous attempts just seem to disappear into the void, even though > several people seemed to think it was a good idea. > > diff --git a/init/Kconfig b/init/Kconfig > index a3f83e2..acc0052 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -29,9 +29,10 @@ config EXPERIMENTAL > , and > in the kernel source). > > - This option will also make obsoleted drivers available. These are > - drivers that have been replaced by something else, and/or are > - scheduled to be removed in a future kernel release. > + At the moment, this option also makes obsolete drivers available, > + but such drivers really should be removed from the EXPERIMENTAL > + category and added to either DEPRECATED or OBSOLETE, depending > + on their status. > > Unless you intend to help test and develop a feature or driver that > falls into this category, or you have a situation that requires > @@ -40,6 +41,29 @@ config EXPERIMENTAL > you say Y here, you will be offered the choice of using features or > drivers that are currently considered to be in the alpha-test phase. > > +config DEPRECATED > + bool "Prompt for deprecated code/drivers" > + default y > + ---help--- > + Code that is tagged as "deprecated" is officially still available > + for use but will typically have already been scheduled for removal > + at some point, so it's in your best interests to start looking for > + an alternative. > + > + Check the file Documentation/feature-removal-schedule.txt to see > + if a particular feature has an official scheduled removal date. > + > +config OBSOLETE > + bool "Prompt for obsolete code/drivers" > + default n > + ---help--- > + Code that is tagged as "obsolete" is officially no longer supported > + and shouldn't play a part in any normal build, but those features > + might still be available if you absolutely need access to them. > + > + You are *strongly* discouraged from continuing to depend on > + obsolete code on an ongoing, long-term basis. > + > config BROKEN > bool - 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] Block layer: separate out queue-oriented ioctls
Alan Stern <[EMAIL PROTECTED]> wrote: > > Alternatively the SG_GET_RESERVED_SIZE ioctl could be > > modified to yield no more than max_sectors*512 . > > There should be one single ioctl which can be applied uniformly to all > CD-type devices (in fact, to all devices using a request_queue) to learn > max_sectors. This rules out using SG_GET_RESERVED_SIZE. This has nothing to do with CD-type devices! It is related to SCSI tansport. > Furthermore, if you changed SG_GET_RESERVED_SIZE in this way you would > only increase the confusion. The reserved size isn't directly related to > the maximum allowed DMA length, and there's no point pretending it is. > What if it turns out that the reserved size is smaller than max_sectors? > Then you'd force user programs to do I/O in chunks that were smaller than > necessary. It would not increase confusion but reduce confusion because all programs would later behave correctly without the need to change them. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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/
AW: [PATCH] Don't probe for DDC on VBE1.2
> Ok it looks like i was corrupting the modelist. The following should take > care of your VAIO, but i haven't tested the failure case as Tobias is away > this weekend. Yes, this last patch also works on VBE 1.2: It skips the EDID calls, which would crash my system here, and consequently boots the kernel fine. Thanks, tobias - 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] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
On Sun, 18 Feb 2007, Bartlomiej Zolnierkiewicz wrote: > Hi, > > Would it be possible to get this patch merged > (or at least DEPRECATED part of it)? > > I think that the patch is useful and that the distinction between > DEPRECATED and OBSOLETE options is quite clear: > > * DEPRECATED == new better code is available, old code scheduled for removal > > * OBSOLETE == no replacement yet but the code is broken by design > and unreliable, not scheduled for removal yet (BTW Robert, I think > CONFIG_OBSOLETE should also be "default y", at least initially) for the most part, that doesn't matter to me one way or the other but, personally, i'd make obsolete kernel features default to "n". after all, if someone has gone to the trouble to actually make that config option *depend* on OBSOLETE, that's a powerful argument that you should have to work a bit to get it back again. :-) but i'm good either way. rday p.s. for people who missed it the first time, a record of the initial discussion is here: http://kerneltrap.org/node/7593 - 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: freezer problems
On Sunday, 18 February 2007 17:19, Oleg Nesterov wrote: > On 02/18, Rafael J. Wysocki wrote: > > > > On Sunday, 18 February 2007 15:52, Oleg Nesterov wrote: > > > > > > And now another problem: exec. de_thread() sleeps in TASK_UNINTERRUPTIBLE > > > waiting for all sub-threads to die, and we have the same "deadlock" if > > > one of them is frozen. This is nasty. Probably we can change the ->state > > > to TASK_INTERRUPTIBLE and add try_to_freeze(), or play with the new PF_ > > > flag, but I am not sure it is safe to freeze() the task which is deep > > > in the exec() path. > > > > Hm, I haven't been aware of this case. > > > > Well, probably we can do something like in the patch that I've just sent: > > the > > child that enters the refrigerator should know that the parent is > > uninterruptible and will wait for it to exit. Thus it can either mark the > > parent as frozen or just exit the refrigerator without freezing itself. > > Sub-thread could already sleep in refrigerator when another thread does exec. > So we have no choice but somehow freeze the execer. But again, I don't know > if it is safe to freeze it here, at de_thread() stage. It is called from > load_xxx_binary(), we may hold some important locks... So it probably isn't safe. Rafael - 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: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug
On Sunday, 18 February 2007 17:11, Oleg Nesterov wrote: > On 02/18, Rafael J. Wysocki wrote: > > > > > On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote: > > > > > > > > A very vague idea: what if parent will do > > > > > > > > current->flags |= > > > > PF_PLEASE_CONSIDER_ME_AS_FROZEN_BUT_SET_TIF_FREEZE > > > > wait_for_completion(&vfork); > > > > try_to_freeze(); > > > > > > > > ? > > > > Hm, what about the following patch instead? > > > > The problem is that if the child enters the refrigeratior, we can't freeze > > the > > parent, because it's uninterruptible, but the child knows the parent will be > > uninterruptible until it exits, so the child can mark the parent as frozen. > > > > --- linux-2.6.20-mm2.orig/kernel/power/process.c2007-02-18 > > 15:43:30.0 +0100 > > +++ linux-2.6.20-mm2/kernel/power/process.c 2007-02-18 16:09:53.0 > > +0100 > > @@ -39,6 +39,13 @@ void refrigerator(void) > > /* Hmm, should we be allowed to suspend when there are realtime > >processes around? */ > > long save; > > + > > + /* The parent is uninterruptible and will stay so until this task exits, > > +* so we can mark it as frozen. > > +*/ > > + if (current->vfork_done) > > + frozen_process(current->parent); > > This is not safe. task->flags is not atomic, we can change ->flags only > if we know the task won't touch it itself (ptrace, thaw_process). > The parent could be interrupted, irq may play with current->flags (slab, > for example). > > Please note that ->parent may do things like ptrace_notify() before > it actually sleeps on ->vfork_done. This means that even if we could > set PF_FROZEN in a safe manner, this doesn't look like a good idea. > > > + > > + if (current->vfork_done && frozen(current->parent)) > > + current->parent->flags &= ~PF_FROZEN; > > } > > Why? If the code above works, we shouldn't take care about frozen > ->parent? I've added this for symmetry. thaw_tasks() should reset PF_FROZEN for it anyway. Okay, so I'll post the patch that implements your idea in the other thread. Greetings, Rafael - 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: freezer problems
On Sunday, 18 February 2007 15:52, Oleg Nesterov wrote:
> On 02/18, Rafael J. Wysocki wrote:
> >
> > On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote:
> > > > >
> > > > > However, this means that sys_vfork() makes impossible to freeze
> > > > > processes
> > > > > until child exits/execs. Not good.
> > > >
> > > I forgot to say that we have another problem: coredumping.
> > >
> > > A thread which does do_coredump() send SIGKILL to ->mm users, and sleeps
> > > on ->mm->core_startup_done. Now it can't be frozen if sub-thread goes to
> > > refrigerator. I think this could be solved easily if we add a check to
> > > refrigerator() as you suggested for ->vfork_donw.
> > >
> > > > I think the real solution would be to use an interruptible completion
> > > > in the
> > > > vfork code. It was discussed some time ago and, IIRC, Ingo had an
> > > > experimental
> > > > patch that implemented it. Still, for the suspend this really is not
> > > > an issue
> > > > in practice, so it wasn't merged.
> > >
> > > It is not (afaics) so trivial to do rightly, and with this change the
> > > parent
> > > will be seen as TASK_INTERRUPTIBLE even without freezer in progress.
> > >
> > > A very vague idea: what if parent will do
> > >
> > > current->flags |= PF_PLEASE_CONSIDER_ME_AS_FROZEN_BUT_SET_TIF_FREEZE
> > > wait_for_completion(&vfork);
> > > try_to_freeze();
> > >
> > > ?
> >
> > This should work,
>
> Good. So try_to_freeze_tasks() can forget about "if (!p->vfork_done)" check.
> This needs more thinking, of course. For example, thaw_process() should be
> carefull to clear TIF_FREEZE if we have the new flag set, but not PF_FROZEN.
> frozen() should be changed to return true if PF_NEW_FLAG && TIF_FREEZE, but
> it also called by refrigerator.
>
> But IF we really can do this, it will be a general solution.
Appended is a patch that does something along these lines. The necessary
thread_info flags are defined for i386 and x86_64, for now.
Greetings,
Rafael
include/asm-i386/thread_info.h |2 ++
include/asm-x86_64/thread_info.h |2 ++
include/linux/freezer.h | 24
kernel/fork.c|4
kernel/power/process.c | 24 +---
5 files changed, 41 insertions(+), 15 deletions(-)
Index: linux-2.6.20-mm2/include/asm-i386/thread_info.h
===
--- linux-2.6.20-mm2.orig/include/asm-i386/thread_info.h2007-02-18
19:49:34.0 +0100
+++ linux-2.6.20-mm2/include/asm-i386/thread_info.h 2007-02-18
19:50:37.0 +0100
@@ -135,6 +135,7 @@ static inline struct thread_info *curren
#define TIF_IO_BITMAP 18 /* uses I/O bitmap */
#define TIF_FREEZE 19 /* is freezing for suspend */
#define TIF_FORCED_TF 20 /* true if TF in eflags artificially */
+#define TIF_FREEZER_SKIP 21 /* task freezer should not count us */
#define _TIF_SYSCALL_TRACE (1<
#include
#include
+#include
#include
#include
@@ -1393,7 +1394,10 @@ long do_fork(unsigned long clone_flags,
tracehook_report_clone_complete(clone_flags, nr, p);
if (clone_flags & CLONE_VFORK) {
+ freezer_do_not_count(current);
wait_for_completion(&vfork);
+ try_to_freeze();
+ freezer_count(current);
tracehook_report_vfork_done(p, nr);
}
} else {
Index: linux-2.6.20-mm2/kernel/power/process.c
===
--- linux-2.6.20-mm2.orig/kernel/power/process.c2007-02-18
19:49:34.0 +0100
+++ linux-2.6.20-mm2/kernel/power/process.c 2007-02-18 19:50:37.0
+0100
@@ -117,22 +117,12 @@ static unsigned int try_to_freeze_tasks(
cancel_freezing(p);
continue;
}
- if (is_user_space(p)) {
- if (!freeze_user_space)
- continue;
-
- /* Freeze the task unless there is a vfork
-* completion pending
-*/
- if (!p->vfork_done)
- freeze_process(p);
- } else {
- if (freeze_user_space)
- continue;
+ if (is_user_space(p) == !freeze_user_space)
+ continue;
- freeze_process(p);
- }
- todo++;
+ freeze_process(p);
+ if (!freezer_should_skip(p))
+ todo++;
} while_each_thread
Partial Oops in 2.6.20?
Hi, I found this this morning on an AMD X2 based system that was unresponsive:ds: 007b es:007b ss:0068 Process events/1 (pid: 7, ti=f7c48000 task=f7d31560 task.ti=f7c48000) Stack: 002c f7d1dc18 0022 f7d1dc18 002c f7d1dc00 c014bfbf f7d28240 f7d2cde4 f7d2cdc0 f7d28240 0202 c1710380 c014d12a c1710384 c17fe240 c01263ca Call Trace: [] drain_array+0x92/0xbd [] cache_reap+0x8e/0x113 [] run_workqueue+0x85/0x125 [] cache_reap+0x0/0x113 [] worker_thread+0xf9/0x124 [] default_wake_function+0x0/0xc [] worker_thread+0x0/0x124 [] kthread+0xb2/0xdd [] kthread+0x0/0xdd [] kernel_thread_helper+0x7/0x10 === Code: 05 03 15 20 d2 4f c0 8b 02 f6 c4 40 74 03 8b 52 0c 8b 02 84 c0 78 04 0f 0b eb 24 28 8b 16 8b 7c 85 34 8b 46 04 <89> 42 04 89 10 2b 4e 0c c7 06 00 01 10 00 c7 4? EIP: [] free_block+0x5f/0xf1 SS:ESP 0068:f7c48f0c <6>note: events1/[7] exited with preempt_count 1 I copied this from a picture I took of the screen. I'm not sure there is enough there to be of any use. It looks like the system was recording a tv show from a BT878 card at the time, using mencoder. Everything is compiled into the kernel, no modules. I haven't seen Oops prior to this on this system. If this is of any use, let me know and I can provide more details on the system - or anything else that might help. Thanks, Art Smith - 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: kbuild question
> > > > Sure, on powerpc for some of the embedded sub-architectures you can only > > select a single board to build for. For a lot of people this is sufficient, > > however we are moving towards a world where you can easily build in support > > for multiple boards into a single kernel. > > > > I'd like to have it such that if I'm only building support for one board > > (CONFIG_ONLY_HAVE_ONE, not going to call it that, but for this discussion > > its > > sufficient), you get a choice menu from Kconfig enforcing the ability to > > only > > select one board. However if !CONFIG_ONLY_HAVE_ONE than you can select > > multiple boards to build into your kernel. > > > > if CONFIG_ONLY_HAVE_ONE is set we can optimize out the runtime checks that > > get > > added for handling the multiple board case. > > On m68k we have the same problem, but what I'm what I'm considering is to > add a new mode for choice groups - at least one must be selected and > kconfig generates the extra information if only one is selected. How about extendign the current 'option' syntax to do this? So we could do something like: choice prompt "choice prompt" default VAL_FIRST option multivalue if !CONFIG_ONLY_HAVE_ONE config VAL_FIRST bool "first" config VAL_SECOND bool "second" endchoice It seems to fit well with how option is used today, and extends current syntax nicely. Sam - 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: PCI riser cards and PCI irq routing, etc
On Sun, Feb 18, 2007 at 05:15:30PM +0100, Udo van den Heuvel wrote: > FYI: My situation is a VIA Epia EN12000 with a TranquilPC dual PCI riser > where only the Device Number can be changed. > The kernel sees the two DVB cards in there as: > > saa7146: register extension 'budget_av'. > ACPI: PCI Interrupt :00:13.0[A] -> GSI 16 (level, low) -> IRQ 16 > saa7146: found saa7146 @ mem f8c3e000 (revision 1, irq 16) (0x153b,0x1157). > saa7146 (0): dma buffer size 192512 > DVB: registering new adapter (Terratec Cinergy 1200 DVB-T). > adapter failed MAC signature check > encoded MAC from EEPROM was > ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff > KNC1-0: MAC addr = 00:0a:ac:01:d6:87 > DVB: registering frontend 0 (Philips TDA10046H DVB-T)... > budget-av: ci interface initialised. > ACPI: PCI Interrupt :00:14.0[A] -> GSI 17 (level, low) -> IRQ 20 > saa7146: found saa7146 @ mem f8cb2000 (revision 1, irq 20) (0x153b,0x1155). > saa7146 (1): dma buffer size 192512 > DVB: registering new adapter (TerraTec Cinergy 1200 DVB-S). > adapter failed MAC signature check > encoded MAC from EEPROM was > ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff > sd 0:0:0:0: Attached scsi generic sg0 type 0 > KNC1-1: MAC addr = 00:0a:ac:12:93:8d > DVB: registering frontend 1 (ST STV0299 DVB-S)... > budget-av: ci interface initialised. Well it says they are slot 13 and 14. What other pci devices are present in the system and what irq's are they using? Now it appears you have acpi, and probably an apic on that board, which would explain having IRQs higher than the 15 a plain old PC had. > So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no > communication with the DVB-T card (the frontend), so there is no > /dev/dvb/* entry. This points to an IRQ problem. Any documentation on that riser card? I guess it is possible the card does something weird and the IRQs for both cards have to actually be the same. If that is the case you could make the kernel change the IRQ assigned to the second card before loading the driver. Or you could do it from the boot loader or something (The system I work with has a stupid bios that doesn't have a clue about bridges, so we added IRQ fixup code to grub to deal with all PCI bridges before booting the system). > How can I find out the actual IRQ that the card is using? > If it is different from what Linux thinks: how do I tell Linux? Linux doesn't think anything. It goes by the IRQ assigned to the device, which is in one of the PCI registers on each device. You can change those registers though, and then it should use the new value (although you may have to change it from the kernel before it enumerates the pci devices). > > On a PC, the BIOS is supposed to assign interrupts to devices based on > > those rules, since that is how the hardware must be done according to > > the PCI specifications. > > I set the BIOS for 'PnP OS installed'. Should I change that? I would NEVER do that. That actually disables the BIOS from doing configuration of most hardware since it really means "Microsoft wants to do configuration themselves and asked us to put in a setting to make the bios only configure drive controllers and sound cards". I know some people have worked towards making linux a "PnP OS" by microsoft standards, but whether it is entirely there or not by now I am not sure. Fortunately most motherboards I have ever bought come preset at 'pnp os installed' off, which is how I like it. I have had a number of problems on systems with that setting on, which went away when the setting was set back to off. It might actually work better if you change that, although it may also just make no difference. -- Len Sorensen - 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: e2b2rom_init_one(): Unable to register resource
On Sun, Feb 18, 2007 at 07:49:34PM +0200, Dan Aloni wrote: | > Making window->phys u32 seems like a cleaner fix. | > (untested) | | With this fix it still looks somewhat broken: | Actually, Dan, I even don't know to do :( May be Andi know... I think the problem is 'cause pci_read_config_word returns 0x4 and window->phys remains on 0. Cyrill - 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.20-mm2: Oops in generic_make_request
On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili <[EMAIL PROTECTED]> wrote: > On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: > > Le 18.02.2007 06:51, Andrew Morton a écrit : > > >Temporarily at > > > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > > > >Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > > > Hello, I've got a fully reproducible Oops. I just have to boot to > > runlevel 2 and wait less than one minute. > > Maybe this oops is related too? Looks that way. > Can't yet tell if it's easily reproducible, this is on a JFS filesystem. > > BUG: unable to handle kernel NULL pointer dereference at virtual address > 0004 > printing eip: > c02206aa > *pde = > Oops: [#1] > PREEMPT > last sysfs file: /devices/pci:00/:00:00.0/class > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010297 (2.6.20-mm2-1 #1) > EIP is at __make_request+0x13a/0x390 > eax: ebx: ecx: 042b0dd8 edx: 00010485 > esi: c5f8cea0 edi: cfd587f8 ebp: c653dadc esp: c653dabc > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Process sh (pid: 4549, ti=c653c000 task=ccca2090 task.ti=c653c000) > Stack: c137eae8 0001 cfd587e4 c5f8cea0 c5f893e4 c137eae8 c5f8cea0 > 0008 >c653db28 c021e0ca cfa3ffa0 cee6a2e0 cfa3ffa0 0008 > 0100 >00011250 cfedaf60 c653db10 0206 c653db18 c014a31e > c653db48 > Call Trace: > [] show_trace_log_lvl+0x1a/0x30 > [] show_stack_log_lvl+0xa9/0xd0 > [] show_registers+0x206/0x350 > [] die+0x10e/0x210 > [] do_page_fault+0x2d2/0x600 > [] error_code+0x74/0x7c > [] generic_make_request+0x15a/0x200 > [] submit_bio+0x58/0xe0 > [] metapage_writepage+0x18f/0x1b0 > [] __writepage+0xb/0x30 > [] write_cache_pages+0x22f/0x300 > [] generic_writepages+0x23/0x30 > [] do_writepages+0x5c/0x60 > [] __filemap_fdatawrite_range+0x67/0x80 > [] filemap_flush+0x25/0x30 > [] lmLogSync+0x19d/0x230 > [] lmLog+0x5e/0x190 > [] txCommit+0x8c0/0x1010 > [] jfs_create+0x324/0x370 > [] vfs_create+0xaf/0x100 > [] open_namei+0x58c/0x640 > [] do_filp_open+0x2c/0x50 > [] do_sys_open+0x47/0xe0 > [] sys_open+0x1c/0x20 > [] syscall_call+0x7/0xb Michal Piotrowski is hitting it too, and has bisected it down to git-block.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: 2.6.20-mm2
On Sun, 18 Feb 2007 13:44:54 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
wrote:
> On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
> >
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.20-mm2/
> >
> > Will appear later at
> >
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
>
> Two problems:
>
> 1) A showstopper with the root partition on RAID1:
>
> md: raid1 personality registered for level 1
> [--snip--]
> md: multipath personality registered for level -4
> register_blkdev: failed to get major for mdp
> [--snip--]
> VFS: Cannot open root device "md1" or unknown-block(0,0)
Someone else reported that against mainline. Can you please debug it a bit?
I'd suggested reverting the recent changes in there:
--- a/block/genhd.c~a
+++ a/block/genhd.c
@@ -61,14 +61,6 @@ int register_blkdev(unsigned int major,
/* temporary */
if (major == 0) {
for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
- /*
-* Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
-* majors
-*/
- if ((60 <= index && index <= 63) ||
- (120 <= index && index <= 127) ||
- (240 <= index && index <= 254))
- continue;
if (major_names[index] == NULL)
break;
}
_
but I don't see how they could cause this.
> At the moment I have no serial console attached to the box, so I had to
> rewrite
> the messages manually.
netconsole is good.
> 2) On HPC nx6325 I get the following 100% of the time during the resume from
> disk:
>
> BUG: at drivers/pci/pci.c:823 pcim_enable_device()
>
> Call Trace:
> [] pcim_enable_device+0x93/0xb3
> [] ata_pci_device_do_resume+0x21/0x5e
> [] sil_pci_device_resume+0x1c/0x51
> [] pci_device_resume+0x22/0x53
> [] resume_device+0xca/0x131
> [] dpm_resume+0x81/0xd3
> [] device_resume+0x30/0x45
> [] snapshot_ioctl+0x245/0x63e
> [] do_ioctl+0x5e/0x77
> [] vfs_ioctl+0x25c/0x279
> [] sys_ioctl+0x5f/0x82
> [] sys_write+0x47/0x70
> [] system_call+0x7e/0x83
>
> Nevertheless, the system seems to be fully functional after the resume.
>
> [I've been observing it since 2.6.20-git10 and have reported it for a couple
> of times, but apparently nobody cares. :-(]
This is a Tejun thing - apparently it's due to swsusp calling suspend once
and resume twice (or is it vice versa). He'll be looking into it soon.
-
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/
[BUG/WARN] Error initialising drivers in PCI
I'm getting this in my logs when starting up after going from a
2.6.20rc5 kernel (which didn't do this) to Linus' latest tree as of 36
hours ago:
Feb 18 14:52:32 localhost kernel: [ 16.392136] Uniform
Multi-Platform E-IDE driver Revision: 7.00alpha2
Feb 18 14:52:32 localhost kernel: [ 16.392210] ide: Assuming 33MHz
system bus speed for PIO modes; override with idebus=xx
Feb 18 14:52:32 localhost kernel: [ 16.395039] Probing IDE interface ide0...
Feb 18 14:52:32 localhost kernel: [ 16.780057] hda: ST315310A, ATA DISK drive
Feb 18 14:52:32 localhost kernel: [ 17.391365] Probing IDE interface ide1...
Feb 18 14:52:32 localhost kernel: [ 18.184752] hdc: LTN485, ATAPI
CD/DVD-ROM drive
Feb 18 14:52:32 localhost kernel: [ 18.490570] ide0 at
0x1f0-0x1f7,0x3f6 on irq 14
Feb 18 14:52:32 localhost kernel: [ 18.490978] ide1 at
0x170-0x177,0x376 on irq 15
Feb 18 14:52:32 localhost kernel: [ 18.493214] hda: max request size: 128KiB
Feb 18 14:52:32 localhost kernel: [ 18.493735] hda: 29336832 sectors
(15020 MB) w/2048KiB Cache, CHS=29104/16/63
Feb 18 14:52:32 localhost kernel: [ 18.493899] hda: cache flushes
not supported
Feb 18 14:52:32 localhost kernel: [ 18.494530] hda: hda1 hda2 < hda5 >
Feb 18 14:52:32 localhost kernel: [ 18.536466] ata_piix
:00:1f.1: version 2.00ac7
Feb 18 14:52:32 localhost kernel: [ 18.536579] ata: 0x1F0 IDE port busy
Feb 18 14:52:32 localhost kernel: [ 18.536583] ata: conflict with ide0
Feb 18 14:52:32 localhost kernel: [ 18.536719] BUG: at
drivers/pci/pci.c:840 pcim_pin_device()
Feb 18 14:52:32 localhost kernel: [ 18.536786] []
show_trace_log_lvl+0x1a/0x2f
Feb 18 14:52:32 localhost kernel: [ 18.536897] []
show_trace+0x12/0x14
Feb 18 14:52:32 localhost kernel: [ 18.536991] []
dump_stack+0x16/0x18
Feb 18 14:52:32 localhost kernel: [ 18.537085] []
pcim_pin_device+0x40/0x4d
Feb 18 14:52:32 localhost kernel: [ 18.537201] []
ata_pci_init_one+0x1ac/0x4bb
Feb 18 14:52:32 localhost kernel: [ 18.537330] []
piix_init_one+0x418/0x435
Feb 18 14:52:32 localhost kernel: [ 18.537431] []
pci_device_probe+0x39/0x5b
Feb 18 14:52:32 localhost kernel: [ 18.537528] []
really_probe+0xbd/0x145
Feb 18 14:52:32 localhost kernel: [ 18.537638] []
driver_probe_device+0x95/0xa1
Feb 18 14:52:32 localhost kernel: [ 18.537734] []
__driver_attach+0x6a/0xa1
Feb 18 14:52:32 localhost kernel: [ 18.537829] []
bus_for_each_dev+0x36/0x5b
Feb 18 14:52:32 localhost kernel: [ 18.537925] []
driver_attach+0x19/0x1b
Feb 18 14:52:32 localhost kernel: [ 18.538019] []
bus_add_driver+0x6a/0x170
Feb 18 14:52:32 localhost kernel: [ 18.538114] []
driver_register+0x79/0x7e
Feb 18 14:52:32 localhost kernel: [ 18.538209] []
__pci_register_driver+0x7b/0xa8
Feb 18 14:52:32 localhost kernel: [ 18.538381] []
piix_init+0x14/0x27
Feb 18 14:52:32 localhost kernel: [ 18.538496] [] init+0x95/0x17a
Feb 18 14:52:32 localhost kernel: [ 18.538597] []
kernel_thread_helper+0x7/0x10
Feb 18 14:52:32 localhost kernel: [ 18.538693] ===
Feb 18 14:52:32 localhost kernel: [ 18.538752] ata: 0x170 IDE port busy
Feb 18 14:52:32 localhost kernel: [ 18.538756] ata: conflict with ide1
Feb 18 14:52:32 localhost kernel: [ 18.538905] ata_piix: probe of
:00:1f.1 failed with error -16
Kernel is standard tree with no modifications.
Relevant code which triggers this from devices/pci/pci.c is:
void pcim_pin_device(struct pci_dev *pdev)
{
struct pci_devres *dr;
dr = find_pci_dr(pdev);
WARN_ON(!dr || !dr->disable);
if (dr)
dr->disable = 0;
}
and it is the WARN_ON that is the line.
.config of kernel is attached.
output of lspci -vv is attached.
Can you please cc me on any discussions/requests as not subscribed to lkml.
NB Machine continues with boot and can run after this. Machine is a
little unstable though but could also be Broadcom 4306 issues as not
sure these drivers are yet stable on my machine...
Ian
--
Web: http://wand.net.nz/~iam4
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group
config.gz
Description: GNU Zip compressed data
00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory
Controller Hub (rev 02)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-
00:02.0 VGA compatible controller: Intel Corporation 82815 CGC [Chipset
Graphics Controller] (rev 02) (prog-if 00 [VGA])
Subsystem: Compaq Computer Corporation Unknown device 0019
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR-
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 01) (prog-if 00
[Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap- 66
Re: 2.6.20-mm2: Oops in generic_make_request
On 18/02/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili <[EMAIL PROTECTED]> wrote: > On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: > > Le 18.02.2007 06:51, Andrew Morton a écrit : > > >Temporarily at > > > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > > > >Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > > > Hello, I've got a fully reproducible Oops. I just have to boot to > > runlevel 2 and wait less than one minute. > > Maybe this oops is related too? Looks that way. > Can't yet tell if it's easily reproducible, this is on a JFS filesystem. > > BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 > printing eip: > c02206aa > *pde = > Oops: [#1] > PREEMPT > last sysfs file: /devices/pci:00/:00:00.0/class > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010297 (2.6.20-mm2-1 #1) > EIP is at __make_request+0x13a/0x390 > eax: ebx: ecx: 042b0dd8 edx: 00010485 > esi: c5f8cea0 edi: cfd587f8 ebp: c653dadc esp: c653dabc > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Process sh (pid: 4549, ti=c653c000 task=ccca2090 task.ti=c653c000) > Stack: c137eae8 0001 cfd587e4 c5f8cea0 c5f893e4 c137eae8 c5f8cea0 0008 >c653db28 c021e0ca cfa3ffa0 cee6a2e0 cfa3ffa0 0008 0100 >00011250 cfedaf60 c653db10 0206 c653db18 c014a31e c653db48 > Call Trace: > [] show_trace_log_lvl+0x1a/0x30 > [] show_stack_log_lvl+0xa9/0xd0 > [] show_registers+0x206/0x350 > [] die+0x10e/0x210 > [] do_page_fault+0x2d2/0x600 > [] error_code+0x74/0x7c > [] generic_make_request+0x15a/0x200 > [] submit_bio+0x58/0xe0 > [] metapage_writepage+0x18f/0x1b0 > [] __writepage+0xb/0x30 > [] write_cache_pages+0x22f/0x300 > [] generic_writepages+0x23/0x30 > [] do_writepages+0x5c/0x60 > [] __filemap_fdatawrite_range+0x67/0x80 > [] filemap_flush+0x25/0x30 > [] lmLogSync+0x19d/0x230 > [] lmLog+0x5e/0x190 > [] txCommit+0x8c0/0x1010 > [] jfs_create+0x324/0x370 > [] vfs_create+0xaf/0x100 > [] open_namei+0x58c/0x640 > [] do_filp_open+0x2c/0x50 > [] do_sys_open+0x47/0xe0 > [] sys_open+0x1c/0x20 > [] syscall_call+0x7/0xb Michal Piotrowski is hitting it too, and has bisected it down to git-block.patch. I have bisected it down to this patches revert-md-avoid-possible-bug_on-in-md-bitmap-handling-for-git-block.patch git-block.patch git-block-fixup.patch git-block-dupe-definitions.patch git-block-xfs-barriers-broke.patch Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - 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: e2b2rom_init_one(): Unable to register resource
On Sun, Feb 18, 2007 at 07:49:34PM +0200, Dan Aloni wrote: | On Sun, Feb 18, 2007 at 06:13:38PM +0100, Andi Kleen wrote: | > [adding mtd maintainer] | > | > On Sunday 18 February 2007 11:42, Cyrill Gorcunov wrote: | > > On Sat, Feb 17, 2007 at 11:29:19PM +0200, Dan Aloni wrote: | > > | Hello, | > > | | > > | I'm running the x86_64 arch of Linux 2.6.20 on a Supermicro X6DH8-XG2 | > > | board and I got this during boot: | > > | | > > | [248660.950695] device id = 2440 | > > | [248660.950699] device id = 2480 | > > | [248660.950703] device id = 24c0 | > > | [248660.950706] device id = 24d0 | > > | [248660.950709] matched device = 24d0 | > > | [248660.950712] matched device id 24d0 | > > | [248660.950716] pci_read_config_byte : 4 | > > | [248660.950723] esb2rom: esb2rom_init_one(): Unable to register resource | > > | 0xffc0-0x - kernel bug? | > > | [248660.950729] esb2rom: ioremap(ffc0, 10040) failed | > > | [248660.956859] retVal = -19 | > > | | > > | Looks like some kind of a 64-bit portability bug... | [...] | > | > Making window->phys u32 seems like a cleaner fix. | > (untested) | | With this fix it still looks somewhat broken: | | [889227.698252] device id = 2440 | [889227.698261] device id = 2480 | [889227.698264] device id = 24c0 | [889227.698268] device id = 24d0 | [889227.698271] matched device = 24d0 | [889227.698274] matched device id 24d0 | [889227.698280] pci_read_config_byte : 4 | [889227.698289] esb2rom: esb2rom_init_one(): Unable to register resource 0xffc0-0x - kernel bug? | [889227.700676] CFI: Found no esb2rom @ffc0 device at location zero | [889227.717995] JEDEC: Found no esb2rom @ffc0 device at location zero | [889227.720811] CFI: Found no esb2rom @ffc0 device at location zero | [889227.747009] JEDEC: Found no esb2rom @ffc0 device at location zero | [889227.748692] CFI: Found no esb2rom @ffc0 device at location zero | [889227.763736] JEDEC: Found no esb2rom @ffc0 device at location zero | [889227.765438] CFI: Found no esb2rom @ffc1 device at location zero | [889227.782755] JEDEC: Found no esb2rom @ffc1 device at location zero | [889227.785566] CFI: Found no esb2rom @ffc1 device at location zero | [889227.810647] JEDEC: Found no esb2rom @ffc1 device at location zero | [889227.812330] CFI: Found no esb2rom @ffc1 device at location zero | [889227.827378] JEDEC: Found no esb2rom @ffc1 device at location zero | [889227.829081] CFI: Found no esb2rom @ffc2 device at location zero | [889227.846390] JEDEC: Found no esb2rom @ffc2 device at location zero | [889227.849202] CFI: Found no esb2rom @ffc2 device at location zero | [889227.874279] JEDEC: Found no esb2rom @ffc2 device at location zero | [889227.875961] CFI: Found no esb2rom @ffc2 device at location zero | [889227.891005] JEDEC: Found no esb2rom @ffc2 device at location zero | [889227.892710] CFI: Found no esb2rom @ffc3 device at location zero | [889227.910022] JEDEC: Found no esb2rom @ffc3 device at location zero | [889227.912835] CFI: Found no esb2rom @ffc3 device at location zero | [889227.937915] JEDEC: Found no esb2rom @ffc3 device at location zero | [889227.939594] CFI: Found no esb2rom @ffc3 device at location zero | [889227.954636] JEDEC: Found no esb2rom @ffc3 device at location zero | [889227.956339] CFI: Found no esb2rom @ffc4 device at location zero | [889227.973647] JEDEC: Found no esb2rom @ffc4 device at location zero | [889227.976461] CFI: Found no esb2rom @ffc4 device at location zero | [889228.001560] JEDEC: Found no esb2rom @ffc4 device at location zero | [889228.003243] CFI: Found no esb2rom @ffc4 device at location zero | [889228.018296] JEDEC: Found no esb2rom @ffc4 device at location zero | [889228.02] CFI: Found no esb2rom @ffc5 device at location zero | [889228.037315] JEDEC: Found no esb2rom @ffc5 device at location zero | [889228.040129] CFI: Found no esb2rom @ffc5 device at location zero | [889228.065218] JEDEC: Found no esb2rom @ffc5 device at location zero | [889228.066899] CFI: Found no esb2rom @ffc5 device at location zero | [889228.081943] JEDEC: Found no esb2rom @ffc5 device at location zero | [889228.083640] CFI: Found no esb2rom @ffc6 device at location zero | [889228.100949] JEDEC: Found no esb2rom @ffc6 device at location zero | [889228.103760] CFI: Found no esb2rom @ffc6 device at location zero | [889228.128850] JEDEC: Found no esb2rom @ffc6 device at location zero | [889228.130529] CFI: Found no esb2rom @ffc6 device at location zero | [889228.145575] JEDEC: Found no esb2rom @ffc6 device at location zero | [889228.147275] CFI: Found no esb2rom @ffc7 device at location zero | [889228.164593] JEDEC: Found no esb2rom @ffc7 device at location zero | [889228.167398] CFI: Found no esb2rom @ffc7 device at location zero | [889228.192491] JEDEC: Found no esb2rom @ffc7 de
