Re: [PATCH] at91_mci: minor cleanup
On Wed, 30 Jan 2008 17:45:48 +0100 Nicolas Ferre <[EMAIL PROTECTED]> wrote: > From: Marc Pignat <[EMAIL PROTECTED]> > > MMC_POWER_ON is a noop, no need to set the power pin again. > > Signed-off-by: Marc Pignat <[EMAIL PROTECTED]> > Signed-off-by: Nicolas Ferre <[EMAIL PROTECTED]> > --- Perhaps also a WARN_ON() or something in the default case to catch bad invokations? Rgds Pierre signature.asc Description: PGP signature
Re: [RFC v2 5/5] Atmel MCI: Driver for Atmel on-chip MMC controllers
On Tue, 29 Jan 2008 19:10:13 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> +
> +/* Those printks take an awful lot of time... */
> +#ifndef DEBUG
> +static unsigned int fmax = 1500U;
> +#else
> +static unsigned int fmax = 100U;
> +#endif
> +module_param(fmax, uint, 0444);
> +MODULE_PARM_DESC(fmax, "Max frequency in Hz of the MMC bus clock");
> +
I think this was meant to go away.
> +
> +static int req_dbg_open(struct inode *inode, struct file *file)
> +{
And this should go into the core.
> +
> +static int __exit atmci_remove(struct platform_device *pdev)
> +{
> + struct atmel_mci *host = platform_get_drvdata(pdev);
> +
> + platform_set_drvdata(pdev, NULL);
> +
> + if (host) {
> + atmci_cleanup_debugfs(host);
> +
> + if (host->detect_pin >= 0) {
> + free_irq(gpio_to_irq(host->detect_pin),host->mmc);
> + cancel_delayed_work(&host->mmc->detect);
I also pointed this out. mmc_remove_host() will synchronize this for
you.
--
-- 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/
keyboard dead with 45b5035
The patch "[RTNETLINK]: Send a single notification on device state changes." kills (at least) the keyboard here. Everything seems to work fine in single user mode, but when init starts spawning of logins, the keyboard goes bye-bye. Even the power button is ignored. :/ I've tried just creating another vt with "chvt 2", but that is insufficient to trigger the bug. 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: keyboard dead with 45b5035
On Mon, 18 Feb 2008 20:50:01 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Monday, 18 of February 2008, Pierre Ossman wrote: > > The patch "[RTNETLINK]: Send a single notification on device state > > changes." kills (at least) > > the keyboard here. Everything seems to work fine in single user mode, but > > when init starts > > spawning of logins, the keyboard goes bye-bye. Even the power button is > > ignored. :/ > > Please try with the patch from http://lkml.org/lkml/2008/2/18/331 . > That solved it. I wonder if that's also why modprobe tends to wedge up with the new USB announce thingy... Tomorrow's debugging will tell. -- -- 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: keyboard dead with 45b5035
On Mon, 18 Feb 2008 21:50:12 +0100 Pierre Ossman <[EMAIL PROTECTED]> wrote: > On Mon, 18 Feb 2008 20:50:01 +0100 > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > On Monday, 18 of February 2008, Pierre Ossman wrote: > > > The patch "[RTNETLINK]: Send a single notification on device state > > > changes." kills (at least) > > > the keyboard here. Everything seems to work fine in single user mode, but > > > when init starts > > > spawning of logins, the keyboard goes bye-bye. Even the power button is > > > ignored. :/ > > > > Please try with the patch from http://lkml.org/lkml/2008/2/18/331 . > > > > That solved it. > Perhaps not quite. When I returned to my laptop this morning, the keyboard was gone again. Did a hard reboot, and the machine locked up a few seconds after starting X. I'll see if it can be reproduced... 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/
random wedges with 2.6.25-rc*
Somewhere post 2.6.24, the kernel started getting very temperamentful. I experience random hangs and wedges very often. Primarily, the udev startup locks up. If I abort it, it just locks up on more or less every action after that. Some quick debugging showed that I had a whole bunch of modprobe processes sitting around. The new CONFIG_USB_ANNOUNCE_NEW_DEVICES setting makes every startup of udev lock up consistently on at least two machines. It does not seem to be the root of the problem as disabling the option just makes the bug very unlikely. I've also seen a couple of lockups in X. Might be a different expression of the same bug, but the effect here is a complete wedge of the user interface. It seems the rest of the machine also locks up, but I haven't confirmed this. Anyone else seeing these problems? Someone should as I've seen the problem on both a Lenovo and a HP laptop here. 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: random wedges with 2.6.25-rc*
On Tue, 19 Feb 2008 12:55:13 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Pierre Ossman wrote: > > > > Anyone else seeing these problems? Someone should as I've seen the problem > > on both a Lenovo and a HP laptop here. > > > I'm definitely seeing lockups here too. 2.6.24 is fine, 2.6.24-rc1 or > -rc2 locks up a minute or so after a successful boot (either to console > or to X). > > Does the following shed any light? > > http://lkml.org/lkml/2008/2/17/78 > That would explain the lockups in X as the network has been active at those times. But it would be odd if it affects the startup of udev (most likely module loading). 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: [Bug 10030] Suspend doesn't work when SD card is inserted
On Wed, 20 Feb 2008 11:42:56 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > > > > --- Comment #14 from [EMAIL PROTECTED] 2008-02-19 15:23 --- > > Thanks a lot for the debugging work! > > > > First, the patch triggers, which means that the problem discovered by Alan > > is > > troubling us. [Alan, do you have an idea how to fix that cleanly?] > > I suggest we ask the maintainer for the MMC subsystem. > > Pierre, you can find the details in the bugzilla entry. Briefly, > there's a pathway in the MMC core suspend routine (if the driver > doesn't implement a resume hook) which could lead to the host being > removed during a system suspend. This is an illegal operation and it > will deadlock. > > Do you have a suggestion for a way to fix it? > Not really. But you have some things confused. What it checks is if the mmc bus handler (not a proper driver model, just a way of separating the MMC, SD and SDIO stuff) has a resume function. And if it doesn't, it removes the card (since it cannot revive it at resume). So the only thing I can think of is to delay the removal until the resume routine, if that is safer. 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: [Bug 10030] Suspend doesn't work when SD card is inserted
On Wed, 20 Feb 2008 14:26:16 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > > Do I understand this correctly? You've got special handling for the > case where a bus handler doesn't have a resume routine, but no special > handling for the case where it doesn't have a suspend routine? Hmm... There should be checks for both, but the code seems to suggest otherwise. > Why bother to remove the device if neither routine exists (there won't be > any need to revive it since the bus never got suspended)? The bus always gets suspended. The checks are to determine if state is saved or not. If it isn't, then a suspend/resume is treated as a removal/insertion. > And why not simply fail the suspend if the resume routine doesn't exist > and the suspend routine does? Maybe with an error message in the > system log. For the asymmetric case, I guess that would do. But I still want to remove devices when the bus handler has no suspend handling. 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 v2] mmc: extend ricoh_mmc to support Ricoh RL5c476
On Mon, 4 Feb 2008 19:25:42 +0100
Frank Seidel <[EMAIL PROTECTED]> wrote:
> From: Frank Seidel <[EMAIL PROTECTED]>
>
> This patch (base on current linus git tree plus Philip Langdales
> suspend/resume patch) adds support for the Ricoh RL5c476 chip:
> with this the mmc adapter that needs this disabler (R5C843) can
> also be handled correctly when it sits on a RL5c476.
> (+ minor style changes (removed spaces between function names
> and open parenthesis .. checkpatch warned from previos patch))
>
> Signed-off-by: Frank Seidel <[EMAIL PROTECTED]>
I see you've guys have kept yourself busy in my absence. :)
As for the patch, it looks ok although I'm not really a fan of more voodoo
constants that noone knows what they mean. Could you add some comments
explaining some of them at least?
> + if (fw_dev->device == PCI_DEVICE_ID_RICOH_RL5C476) {
*snip*
> + } else {
> + /* via R5C832 */
Wouldn't it be prudent to have a check that this is indeed a R5C832, and a
failure mode if it's none of the two known devices?
Rgds
Pierre
signature.asc
Description: PGP signature
Re: [semi-solved] Re: [sdhci] mmc0: unrecognised SCR structure version 1
On Thu, 7 Feb 2008 00:10:16 +0100 Andreas Mohr <[EMAIL PROTECTED]> wrote: > > My Toshiba SD-512-T card (Toshiba-specific specs are available as > TOSHIBA_SD_Card_Specification.pdf) shows the same "SCR structure version 1" > error message with 2.6.24 on a Motorola E680 (PXAMCI), whereas > on 2.6.21 it did _NOT_ have it (and all SCR values there are a 1:1 match > with the values listed in the spec .pdf!). > > For me at least it turned out that while on 2.6.21, raw_scr had > 0x00a5 0x10011602 > on 2.6.24 raw_scr had > 0x10011602 0x > Ouch. That would explain more or less any SCR related bug. :) > IOW, the whole thing is simply shifted by one unsigned int, rendering any > SCR interpretation fatally wrong (which, I believe, could be a > _permanent_ error in the SD stack itself which randomly - > depending on the exact bit content of a card's SCR dump - > causes the SCR version check to trigger for various cards). > Is this unsigned int shifting due to a transfer setup issue in the > highlevel SD stack or do you think it is due to a setup issue in the > lower-level pxamci driver in my case? If so, what setting could have > distorted it? I'm not seeing it on any controller here, so right now I'd guess a driver problem. No idea why though. Are you seeing this effect on other cards? > Weak voltage settings are not to blame, I believe (removed some configs to > increase a bit from minimum supported voltage). > If you don't have any specific ideas yet, any hints on how to proceed > with tracking this down? There's always bisecting the issue until you find the offending commit. Time consuming, but it gets the job done. Other than that, try adding some printk() to pxamci's data transfer routines and dump the data when it is fresh. > > I'd advise at least adding dumping the raw_scr values > in the SCR version error to be able to track such error postings better > in the future. > It's definitely something to remember in future bug reports. 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 v2] mmc: extend ricoh_mmc to support Ricoh RL5c476
On Thu, 7 Feb 2008 09:20:38 +0100 Frank Seidel <[EMAIL PROTECTED]> wrote: > > > > Wouldn't it be prudent to have a check that this is indeed a R5C832, > > and a failure mode if it's none of the two known devices? > > Also thought about that, but as far as i can see this cannot happen since > we only probe for those two devices and deny to continue if anything else > /those two were not found in the beginning. > Can never be too careful though. :) I've applied the patch for now. Feel free to keep digging and finding some docs for those regs though. Rgds Pierre signature.asc Description: PGP signature
Re: SDIO driver not receiving responses
Don't hijack threads, it completely messes up everyone's mail box and makes your mail very difficult to find. On Thu, 31 Jan 2008 17:35:51 +1100 Farbod Nejati <[EMAIL PROTECTED]> wrote: > The mmc_send_io_op_cond() function call in core.c::mmc_rescan() is > returning with a -110 (a timeout error). I traced this deeper and > noticed that CMD5 is being sent out via sdhci.c::sdhci_send_command() (I > verified this using a logic analyser, the host *is* transmitting a CMD5 > [IO_SEND_OP_COND] packet in the correct format). However, when the > client responds with the IO_SEND_OP_COND Response R4 (SD mode), it does > not seem to be received by the host. Again, I verified using the logic > analyser that the response is as would be expected. An IRQ *is* > triggered, however it is 0x00018000 (SDHCI_INT_TIMEOUT|SDHCI_INT_ERROR). > I'm not too familiar with Linux kernel programming but I suspect that > whatever is waiting for a valid response is giving up instead and > triggering the above-mentioned interrupt instead. That would be the hardware. We don't do any software timeout handling. Have you checked the time from command to reply with the logic analyser? The chip might simply be out of spec. > > Why would the output of the above code differ from the one produced by > lspci -xxx. Could this have something to do with this issue??? > lspci shows you the PCI config space, not the device io space, which is what your code dumped. ;) > > I'm fresh out of ideas on this one and would greatly appreciate some > hints or assistance. I'm happy to provide any further information if needed. > I can only see one of two options here. Either there is some miscalculation of the timeout, or you have a hardware bug. And to determine that we need to check what is actually going over the wire. As you've checked the data contents, that isn't the problem. So the only remaining thing is checking the timing. 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 05/18] MMC: OMAP: Introduce new multislot structure and change driver to use it
On Mon, 28 Jan 2008 15:07:23 -0400
Carlos Aguiar <[EMAIL PROTECTED]> wrote:
> From: Juha Yrjola <[EMAIL PROTECTED]>
>
> Introduce new MMC multislot structure and change driver to use it.
>
> Note that MMC clocking is now enabled in mmc_omap_select_slot()
> and disabled in mmc_omap_release_slot().
>
> Signed-off-by: Juha Yrjola <[EMAIL PROTECTED]>
> Signed-off-by: Jarkko Lavinen <[EMAIL PROTECTED]>
> Signed-off-by: Carlos Eduardo Aguiar <[EMAIL PROTECTED]>
> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
> ---
I still think this muxed mmc host thing is a bad idea, but it's your
nightmare...
> +
> +/* Access to the R/O switch is required for production testing
> + * purposes. */
> +static ssize_t
> +mmc_omap_show_ro(struct device *dev, struct device_attribute *attr, char
> *buf)
> +{
> + struct mmc_host *mmc = container_of(dev, struct mmc_host, class_dev);
> + struct mmc_omap_slot *slot = mmc_priv(mmc);
> +
> + return sprintf(buf, "%d\n", slot->pdata->get_ro(mmc_dev(mmc),
> + slot->id));
> +}
> +
> +static DEVICE_ATTR(ro, S_IRUGO, mmc_omap_show_ro, NULL);
> +
This is unrelated to the slot stuff and should be in its own patch. Also, it
should probably be in the core, not a driver.
> +
> + mmc->caps = MMC_CAP_MULTIWRITE | MMC_CAP_MMC_HIGHSPEED |
> + MMC_CAP_SD_HIGHSPEED;
This is also unrelated. From what I've seen, the OMAP is a SD controller and
does not support high speed MMC. The fact that you also conditionally set the
max frequency later also suggests that this code is entirely incorrect.
> +
> + r = mmc_add_host(mmc);
> + if (r < 0)
> + return r;
> +
> + if (slot->pdata->name != NULL) {
> + r = device_create_file(&mmc->class_dev,
> + &dev_attr_slot_name);
> + if (r < 0)
> + goto err_remove_host;
> + }
> +
> + if (slot->pdata->get_ro != NULL) {
> + r = device_create_file(&mmc->class_dev,
> + &dev_attr_ro);
> + }
> +
You have a bit of a race here with userspace in case you use the uevent to
trigger things.
--
-- 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] at91_mci: use generic GPIO calls
On Mon, 04 Feb 2008 18:12:48 +0100 Nicolas Ferre <[EMAIL PROTECTED]> wrote: > From: David Brownell <[EMAIL PROTECTED]> > > Update the AT91 MMC driver to use the generic GPIO calls instead of the > AT91-specific calls; and to request (and release) those GPIO signals. > > That required updating the probe() fault cleanup codepaths. Now there > is a single sequence for freeing resources, in reverse order of their > allocation. Also that code uses use dev_*() for messaging, and has less > abuse of KERN_ERR. > > Likewise with updating remove() cleanup. This had to free the GPIOs, > and while adding that code I noticed and fixed two other problems: it > was poking at a workqueue owned by the mmc core; and in one (rare) > case would try freeing an IRQ that it didn't allocate. > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> > Signed-off-by: Nicolas Ferre <[EMAIL PROTECTED]> > --- Applied thanks. -- -- 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 01/18] MMC: OMAP: Include missing from previous merging
On Mon, 28 Jan 2008 15:07:06 -0400 Carlos Aguiar <[EMAIL PROTECTED]> wrote: > From: Carlos Eduardo Aguiar <[EMAIL PROTECTED]> > > This patch adds an include missing from previous merging > mainline tree into linux-omap tree. > > Signed-off-by: Carlos Eduardo Aguiar <[EMAIL PROTECTED]> > Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]> > --- NAK. This header should not be needed in host drivers. It's a clear sign you're doing something bad. 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] Tokyo Electron SDIO controller (Ellen) support
On Mon, 3 Dec 2007 14:39:26 + Ben Dooks <[EMAIL PROTECTED]> wrote: > On Mon, Dec 03, 2007 at 08:22:07AM -0600, Matt Porter wrote: > > > > What's the status of Ben's separation patches? I haven't seen a posting of > > those > > versus a recent kernel. I've got some SDHCI driver glue for the non-pci > > Arasan core > > running in an older kernel tree with those patches. It's just waiting for > > the separation > > patches to hit the mmc or mainline tree. > > I need to go back and try and sort out the last of Pierre's last > comments, and update to the latest kernel version. I was waiting > for 2.6.24-rc4 to re-start the effort to try and ensure there are > fewer changes due to fixes. > Any progress on this little project? Rgds Pierre signature.asc Description: PGP signature
[GIT PULL] MMC updates
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus to receive the following updates: MAINTAINERS |3 - drivers/mmc/host/Kconfig |8 +- drivers/mmc/host/at91_mci.c | 114 +- drivers/mmc/host/ricoh_mmc.c | 162 ++--- drivers/mmc/host/sdhci.c | 13 +++- drivers/mmc/host/sdhci.h |1 + 6 files changed, 231 insertions(+), 70 deletions(-) David Brownell (1): at91_mci: use generic GPIO calls Feng Tang (1): sdhci: add num index for multi controllers case Frank Seidel (1): mmc: extend ricoh_mmc to support Ricoh RL5c476 Philip Langdale (1): mmc: Handle suspend/resume in Ricoh MMC disabler Pierre Ossman (2): mmc: remove sdhci and mmc_spi experimental markers MAINTAINERS: remove non-existant URLs -- -- 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: MMC core debugfs support (was Re: [RFC v2 5/5] Atmel MCI: Driver for Atmel on-chip MMC controllers)
On Thu, 14 Feb 2008 15:00:05 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > > I've started working on this, but I've run into a problem: The mmc core > structures don't seem to keep any references to the current request. So > I don't really have any information to put into the 'req' file after > moving it into the core. > > Any ideas on how to solve this? > The simple solution is just to add it. :) But is it needed though? Shouldn't a read block until there is an event, at which point you'll have access to the data structures long enough to output data. 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: MMC card detection
On Thu, 21 Feb 2008 19:46:20 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > > When the card is reinserted, the MMC core will try to send a > SEND_STATUS command again. This time, the card won't respond because it > is in the "idle" state, and the MMC core will think the card is gone. > > In order to fix this problem, I think I need a way to tell the MMC core > that the card really is gone and that there's no point trying to > communicate with it. Is there any way I can do that? > As you found out, you can. But the MMC core doesn't treat it differently. What is really needed is that the core should make an extra pass and see if the card has been replaced by something else (and not just check if it is gone). It's on my todo, but I haven't had time to implement it. Rgds Pierre signature.asc Description: PGP signature
Re: Bugs in MMC [was: [Bug 10030] Suspend doesn't work when SD card is inserted]
On Sun, 24 Feb 2008 10:33:34 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > > Well, the patch itself isn't really adequate; it was just a first pass > intended to illustrate the nature of the problem. > > The problems in the MMC subsystem go deeper. > > The first is the way it uses flush_workqueue(). This is almost always > a bad function to call, because it introduces unnecessary dependencies. > cancel_delayed_work_sync() is much better. > > But even changing that won't solve the second issue, which is a genuine > bug. There is a race between detect events and suspend events. The > mmc_suspend_host() routine starts out by flushing the kmmcd workqueue > before calling the host's suspend routine. So what happens if another > detect event occurs in between? > The idea is that host drivers shouldn't do that. Once they've called mmc_suspend_host(), then they shouldn't be poking the MMC core in any other way. None of this is of course properly documented. :/ > This whole area of synchronization between card insertion, card > removal, suspend, and resume needs to be thought out better. > Especially keeping in mind that device registration or unregistration > during a system sleep is likely to block until the sleep is over. Trying to keep up with the PM changes is a full time job. For now I've mostly ignored it as I don't even have time for the other stuff. Patches welcome. > > Lastly, there are some other questions about confusing aspects of the > subsystem. What's the story with __mmc_claim_host()? Is it really > nothing more than an abortable mutex_lock()? Why does it ever need to > be aborted? Why is its second argument an atomic_t instead of a normal > int? > It got that way when SDIO got in. It was needed to make it abortable to solve a rather nasty deadlock situation. I don't remember the details right now, but it should be in the LKML archives. > Why are mmc_detect() and related routines described in comments as > "Card detection callback from host"? They don't handle card > _detection_ -- they handle card _removal_. They handle both. > > What's the purpose of the card-counting loop in > host/omap.c:mmc_omap_switch_handler()? It looks like dead code. > I'm not too familiar with that driver, but they've been playing around with multiplexing several cards into one controller. Might be bits and pieces of that. 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: Bugs in MMC [was: [Bug 10030] Suspend doesn't work when SD card is inserted]
On Mon, 25 Feb 2008 12:58:30 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > Thanks for the explanations. > > On Mon, 25 Feb 2008, Pierre Ossman wrote: > > > Trying to keep up with the PM changes is a full time job. For now I've > > mostly ignored it as I don't even have time for the other stuff. > > Patches welcome. > > What do you think of the patch attached to comment #40 in the Bugzilla > entry? > Looks ok. As long as those two synchronization points are guaranteed, then I'm happy. 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/
[PATCH] wbsd version bump
Version increase of the wbsd driver. Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]> Even though the changes are minor for the next release an increasing version number simplifies my support issues. Index: linux/drivers/mmc/wbsd.c === --- linux/drivers/mmc/wbsd.c (revision 151) +++ linux/drivers/mmc/wbsd.c (working copy) @@ -42,7 +42,7 @@ #include "wbsd.h" #define DRIVER_NAME "wbsd" -#define DRIVER_VERSION "1.2" +#define DRIVER_VERSION "1.3" #ifdef CONFIG_MMC_DEBUG #define DBG(x...) \
[PATCH] Fix whitespace in wbsd
Remove lots of trailing whitespace caused by not-so-great editor.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
--- linux/drivers/mmc/wbsd.c.orig 2005-07-11 14:26:40.0 +0200
+++ linux/drivers/mmc/wbsd.c 2005-07-11 14:27:02.0 +0200
@@ -93,7 +93,7 @@
static inline void wbsd_unlock_config(struct wbsd_host* host)
{
BUG_ON(host->config == 0);
-
+
outb(host->unlock_code, host->config);
outb(host->unlock_code, host->config);
}
@@ -101,14 +101,14 @@
static inline void wbsd_lock_config(struct wbsd_host* host)
{
BUG_ON(host->config == 0);
-
+
outb(LOCK_CODE, host->config);
}
static inline void wbsd_write_config(struct wbsd_host* host, u8 reg, u8 value)
{
BUG_ON(host->config == 0);
-
+
outb(reg, host->config);
outb(value, host->config + 1);
}
@@ -116,7 +116,7 @@
static inline u8 wbsd_read_config(struct wbsd_host* host, u8 reg)
{
BUG_ON(host->config == 0);
-
+
outb(reg, host->config);
return inb(host->config + 1);
}
@@ -140,21 +140,21 @@
static void wbsd_init_device(struct wbsd_host* host)
{
u8 setup, ier;
-
+
/*
* Reset chip (SD/MMC part) and fifo.
*/
setup = wbsd_read_index(host, WBSD_IDX_SETUP);
setup |= WBSD_FIFO_RESET | WBSD_SOFT_RESET;
wbsd_write_index(host, WBSD_IDX_SETUP, setup);
-
+
/*
* Set DAT3 to input
*/
setup &= ~WBSD_DAT3_H;
wbsd_write_index(host, WBSD_IDX_SETUP, setup);
host->flags &= ~WBSD_FIGNORE_DETECT;
-
+
/*
* Read back default clock.
*/
@@ -164,12 +164,12 @@
* Power down port.
*/
outb(WBSD_POWER_N, host->base + WBSD_CSR);
-
+
/*
* Set maximum timeout.
*/
wbsd_write_index(host, WBSD_IDX_TAAC, 0x7F);
-
+
/*
* Test for card presence
*/
@@ -177,7 +177,7 @@
host->flags |= WBSD_FCARD_PRESENT;
else
host->flags &= ~WBSD_FCARD_PRESENT;
-
+
/*
* Enable interesting interrupts.
*/
@@ -200,9 +200,9 @@
static void wbsd_reset(struct wbsd_host* host)
{
u8 setup;
-
+
printk(KERN_ERR DRIVER_NAME ": Resetting chip\n");
-
+
/*
* Soft reset of chip (SD/MMC part).
*/
@@ -214,9 +214,9 @@
static void wbsd_request_end(struct wbsd_host* host, struct mmc_request* mrq)
{
unsigned long dmaflags;
-
+
DBGF("Ending request, cmd (%x)\n", mrq->cmd->opcode);
-
+
if (host->dma >= 0)
{
/*
@@ -232,7 +232,7 @@
*/
wbsd_write_index(host, WBSD_IDX_DMA, 0);
}
-
+
host->mrq = NULL;
/*
@@ -275,7 +275,7 @@
host->offset = 0;
host->remain = host->cur_sg->length;
}
-
+
return host->num_sg;
}
@@ -297,12 +297,12 @@
struct scatterlist* sg;
char* dmabuf = host->dma_buffer;
char* sgbuf;
-
+
size = host->size;
-
+
sg = data->sg;
len = data->sg_len;
-
+
/*
* Just loop through all entries. Size might not
* be the entire list though so make sure that
@@ -317,23 +317,23 @@
memcpy(dmabuf, sgbuf, sg[i].length);
kunmap_atomic(sgbuf, KM_BIO_SRC_IRQ);
dmabuf += sg[i].length;
-
+
if (size < sg[i].length)
size = 0;
else
size -= sg[i].length;
-
+
if (size == 0)
break;
}
-
+
/*
* Check that we didn't get a request to transfer
* more data than can fit into the SG list.
*/
-
+
BUG_ON(size != 0);
-
+
host->size -= size;
}
@@ -343,12 +343,12 @@
struct scatterlist* sg;
char* dmabuf = host->dma_buffer;
char* sgbuf;
-
+
size = host->size;
-
+
sg = data->sg;
len = data->sg_len;
-
+
/*
* Just loop through all entries. Size might not
* be the entire list though so make sure that
@@ -363,30 +363,30 @@
memcpy(sgbuf, dmabuf, sg[i].length);
kunmap_atomic(sgbuf, KM_BIO_SRC_IRQ);
dmabuf += sg[i].length;
-
+
if (size < sg[i].length)
size = 0;
else
size -= sg[i].length;
-
+
if (size == 0)
break;
}
-
+
/*
* Check that we didn't get a request to transfer
* more data than can fit into the SG list.
*/
-
+
BUG_ON(size != 0);
-
+
host->size -= size;
}
/*
* Command handling
*/
-
+
static inline void wbsd_get_short_reply(struct wbsd_host* host,
struct mmc_command* cmd)
{
@@ -398,7 +398,7 @@
cmd->error = MMC_ERR_INVALID;
return;
}
-
+
cmd->resp[0] =
wbsd_read_index(host, WBSD_IDX_RESP12) << 24;
cmd->resp[0] |=
@@ -415,7 +415,7 @@
struct mmc_command* cmd)
{
int i;
-
+
/*
* Correct response type?
*/
@@ -424,7 +424,7 @@
cmd->error = MMC_ERR_INVALID;
return;
}
-
+
for (i = 0;i < 4;i++)
{
cmd->resp[i] =
@@ -442,7 +442,7 @@
{
int i;
u8 status, isr;
-
+
DBGF("Sending cmd (%x)\n", cmd->opcode);
/*
@@ -451,16 +451,16 @@
* transfer.
*/
host->isr = 0;
-
+
/*
* Send the command (CRC calculated by host).
*/
outb(cmd->opcode, host->base + WBSD_CMDR);
for (i = 3;i >= 0;i--)
outb((cmd->arg >> (i * 8)) & 0xf
[PATCH] MMC host class
Create a mmc_host class to allow enumeration of MMC host controllers
even though they have no card(s) inserted.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
(This will also allow cards to be enumerated by being able to find the
hosts.)
Index: linux-wbsd/drivers/mmc/mmc.h
===
--- linux-wbsd/drivers/mmc/mmc.h (revision 134)
+++ linux-wbsd/drivers/mmc/mmc.h (working copy)
@@ -13,4 +13,6 @@
void mmc_init_card(struct mmc_card *card, struct mmc_host *host);
int mmc_register_card(struct mmc_card *card);
void mmc_remove_card(struct mmc_card *card);
+int mmc_register_host(struct mmc_host *host);
+void mmc_unregister_host(struct mmc_host *host);
#endif
Index: linux-wbsd/drivers/mmc/mmc_sysfs.c
===
--- linux-wbsd/drivers/mmc/mmc_sysfs.c (revision 153)
+++ linux-wbsd/drivers/mmc/mmc_sysfs.c (working copy)
@@ -20,6 +20,7 @@
#define dev_to_mmc_card(d) container_of(d, struct mmc_card, dev)
#define to_mmc_driver(d) container_of(d, struct mmc_driver, drv)
+#define cls_to_mmc_host(d) container_of(d, struct mmc_host, class_dev)
#define MMC_ATTR(name, fmt, args...) \
static ssize_t mmc_##name##_show (struct device *dev, char *buf) \
@@ -224,14 +225,51 @@
put_device(&card->dev);
}
+static void mmc_host_class_dev_release(struct class_device *dev)
+{
+}
+
+static struct class mmc_host_class = {
+ .name = "mmc_host",
+ .release = &mmc_host_class_dev_release,
+};
+
+/*
+ * Internal function. Register a new MMC host with the MMC class.
+ */
+int mmc_register_host(struct mmc_host *host)
+{
+ host->class_dev.dev = host->dev;
+ host->class_dev.class = &mmc_host_class;
+ strlcpy(host->class_dev.class_id, host->host_name, BUS_ID_SIZE);
+
+ return class_device_register(&host->class_dev);
+}
+
+/*
+ * Internal function. Unregister a MMC host with the MMC class.
+ */
+void mmc_unregister_host(struct mmc_host *host)
+{
+ class_device_unregister(&host->class_dev);
+}
static int __init mmc_init(void)
{
- return bus_register(&mmc_bus_type);
+ int retval;
+
+ retval = bus_register(&mmc_bus_type);
+ if (retval)
+ return retval;
+ retval = class_register(&mmc_host_class);
+ if (retval)
+ return retval;
+ return 0;
}
static void __exit mmc_exit(void)
{
+ class_unregister(&mmc_host_class);
bus_unregister(&mmc_bus_type);
}
Index: linux-wbsd/drivers/mmc/mmc.c
===
--- linux-wbsd/drivers/mmc/mmc.c (revision 153)
+++ linux-wbsd/drivers/mmc/mmc.c (working copy)
@@ -1196,6 +1196,8 @@
snprintf(host->host_name, sizeof(host->host_name),
"mmc%d", host_num++);
+ mmc_register_host(host);
+
mmc_power_off(host);
mmc_detect_change(host);
@@ -1220,6 +1222,8 @@
mmc_remove_card(card);
}
+
+ mmc_unregister_host(host);
mmc_power_off(host);
}
Index: linux-wbsd/include/linux/mmc/host.h
===
--- linux-wbsd/include/linux/mmc/host.h (revision 153)
+++ linux-wbsd/include/linux/mmc/host.h (working copy)
@@ -69,6 +69,7 @@
struct mmc_host {
struct device *dev;
+ struct class_device class_dev;
struct mmc_host_ops *ops;
unsigned int f_min;
unsigned int f_max;
Re: [PATCH] MMC host class
Russell King wrote: >No no no no no. Repeat after me ten times. Empty or non-existant release >functions are bad and cause oopsen. I will not create code which does >this. > > Sorry. I thought it was a generic cleanup function and since nothing was allocated in the register function I didn't think it needed to do anything. I tried to find some documentation about how classes were handled but eventually had to resort to looking at other code. Perhaps I should look at the documentation about kernel objects instead? >What this means is that mmc_host itself becomes a refcounted sysfs >object which needs to follow the lifetime rules associated therewith. > >Luckily, I thought about this earlier on, so there's a core mmc function >to allocate the beast, register it, unregister it, and finally free it. > >The allocation function should initialise class_dev as much as possible. > > The name field cannot be initialised since it isn't generated until registration. And I avoided filling in the other stuff at allocation so that I could keep knowledge of mmc_host_class in mmc_sysfs.c. >The registration function should add the class device with the class >model. The unregistration should remove the class device from the class >model, but _not_ free it. The free function should drop the last >reference to the class device, which results in the remove function >(eventually) being called. Finally, the remove function can free the >mmc_host. > > With the remove function you mean the .release in the class struct? >Also note that since we have a class_dev, the mmc_host 'dev' field can >be removed. However, we'll probably have to update the host drivers >to do this, so it should be a separate patch. > > > I'll read up on kernel objects and sysfs and put together a new patch then. Rgds Pierre - 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] MMC host class
Russell King wrote:
>The allocation function should initialise class_dev as much as possible.
>The registration function should add the class device with the class
>model. The unregistration should remove the class device from the class
>model, but _not_ free it. The free function should drop the last
>reference to the class device, which results in the remove function
>(eventually) being called. Finally, the remove function can free the
>mmc_host.
>
>
New patch according to above system. I've moved the naming a bit earlier
to avoid having a nameless kobj floating around.
>Also note that since we have a class_dev, the mmc_host 'dev' field can
>be removed. However, we'll probably have to update the host drivers
>to do this, so it should be a separate patch.
>
>
>
I believe there's a bit of abstraction to be gained from not poking
around inside the class_dev struct in too many places. It's not like
we're wasting any large amounts of memory.
Rgds
Pierre
Index: linux-wbsd/drivers/mmc/mmc.h
===
--- linux-wbsd/drivers/mmc/mmc.h (revision 134)
+++ linux-wbsd/drivers/mmc/mmc.h (working copy)
@@ -13,4 +13,7 @@
void mmc_init_card(struct mmc_card *card, struct mmc_host *host);
int mmc_register_card(struct mmc_card *card);
void mmc_remove_card(struct mmc_card *card);
+void mmc_init_host(struct mmc_host *host);
+int mmc_register_host(struct mmc_host *host);
+void mmc_unregister_host(struct mmc_host *host);
#endif
Index: linux-wbsd/drivers/mmc/mmc_sysfs.c
===
--- linux-wbsd/drivers/mmc/mmc_sysfs.c (revision 153)
+++ linux-wbsd/drivers/mmc/mmc_sysfs.c (working copy)
@@ -20,6 +20,7 @@
#define dev_to_mmc_card(d) container_of(d, struct mmc_card, dev)
#define to_mmc_driver(d) container_of(d, struct mmc_driver, drv)
+#define cls_dev_to_mmc_host(d) container_of(d, struct mmc_host, class_dev)
#define MMC_ATTR(name, fmt, args...) \
static ssize_t mmc_##name##_show (struct device *dev, char *buf) \
@@ -224,14 +225,64 @@
put_device(&card->dev);
}
+static void mmc_host_class_dev_release(struct class_device *dev)
+{
+ struct mmc_host *host = cls_dev_to_mmc_host(dev);
+ kfree(host);
+}
+
+static struct class mmc_host_class = {
+ .name = "mmc_host",
+ .release = &mmc_host_class_dev_release,
+};
+
+void mmc_init_host(struct mmc_host *host)
+{
+ static unsigned int host_num;
+
+ snprintf(host->host_name, sizeof(host->host_name),
+ "mmc%d", host_num++);
+
+ host->class_dev.dev = host->dev;
+ host->class_dev.class = &mmc_host_class;
+ strlcpy(host->class_dev.class_id, host->host_name, BUS_ID_SIZE);
+
+ class_device_initialize(&host->class_dev);
+ class_device_get(&host->class_dev);
+}
+
+/*
+ * Internal function. Register a new MMC host with the MMC class.
+ */
+int mmc_register_host(struct mmc_host *host)
+{
+ return class_device_add(&host->class_dev);
+}
+
+/*
+ * Internal function. Unregister a MMC host with the MMC class.
+ */
+void mmc_unregister_host(struct mmc_host *host)
+{
+ class_device_unregister(&host->class_dev);
+}
static int __init mmc_init(void)
{
- return bus_register(&mmc_bus_type);
+ int retval;
+
+ retval = bus_register(&mmc_bus_type);
+ if (retval)
+ return retval;
+ retval = class_register(&mmc_host_class);
+ if (retval)
+ return retval;
+ return 0;
}
static void __exit mmc_exit(void)
{
+ class_unregister(&mmc_host_class);
bus_unregister(&mmc_bus_type);
}
Index: linux-wbsd/drivers/mmc/mmc.c
===
--- linux-wbsd/drivers/mmc/mmc.c (revision 153)
+++ linux-wbsd/drivers/mmc/mmc.c (working copy)
@@ -1178,6 +1178,8 @@
host->max_phys_segs = 1;
host->max_sectors = 1 << (PAGE_CACHE_SHIFT - 9);
host->max_seg_size = PAGE_CACHE_SIZE;
+
+ mmc_init_host(host);
}
return host;
@@ -1191,10 +1193,7 @@
*/
int mmc_add_host(struct mmc_host *host)
{
- static unsigned int host_num;
-
- snprintf(host->host_name, sizeof(host->host_name),
- "mmc%d", host_num++);
+ mmc_register_host(host);
mmc_power_off(host);
mmc_detect_change(host);
@@ -1222,6 +1221,8 @@
}
mmc_power_off(host);
+
+ mmc_unregister_host(host);
}
EXPORT_SYMBOL(mmc_remove_host);
@@ -1235,7 +1236,8 @@
void mmc_free_host(struct mmc_host *host)
{
flush_scheduled_work();
- kfree(host);
+
+ class_device_put(&host->class_dev);
}
EXPORT_SYMBOL(mmc_free_host);
Index: linux-wbsd/include/linux/mmc/host.h
===
--- linux-wbsd/include/linux/mmc/host.h (revision 153)
+++ linux-wbsd/include/linux/mmc/host.h (working copy)
@@ -69,6 +69,7 @@
struct mmc_host {
struct device *dev;
+ struct class_device class_dev;
struct mmc_host_ops *ops;
unsigned int f_min;
unsigned int f_max;
Re: [PATCH] MMC host class
Russell King wrote: >On Fri, Jul 15, 2005 at 10:21:43PM +0200, Pierre Ossman wrote: > > >>Russell King wrote: >> >> >>>Also note that since we have a class_dev, the mmc_host 'dev' field can >>>be removed. However, we'll probably have to update the host drivers >>>to do this, so it should be a separate patch. >>> >>> >>I believe there's a bit of abstraction to be gained from not poking >>around inside the class_dev struct in too many places. It's not like >>we're wasting any large amounts of memory. >> >> > >I still don't like the needless duplication. How about doing it this >way (see the attached patch.) > > The mmc_hostname macro seems like a good solution. It'll keep the abstraction even if stuff needs to be moved around. I see a problem with waiting until mmc_add_host() until initialising the kobject though. If a driver calls mmc_alloc_host() and then mmc_free_host(), perhaps because of some error, then the structure won't be freed since we rely on release getting called. That's why I tried to get the kobject stuff set up with the allocation. Perhaps it is possible to test if a kobject is initialised and if not free the structure directly? Rgds Pierre - 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/
IRQ routing problem in 2.6.10-rc2
Sorry about reporting this error so late but the machine in question had gone some time without upgrades. The problem I'm seeing is that IRQs stop working for one of the IRQ slots on the machine. It's only that slot, not the entire IRQ, since the two slots (it's a small machine) both get routed to IRQ 10. I've included dmesg from 2.6.10-rc1 (which works) and 2.6.10-rc2 (which doesn't). I've also tried reverting the patches that modifies arch/i386/kernel/irq.c and arch/i386/pci/irq.c but it didn't solve the problem. So now I need some more input on which patches to try. Rgds Pierre Linux version 2.6.10-rc1 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #3 Sun Jul 17 03:03:28 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0fffe000 (usable) BIOS-e820: 0fffe000 - 1000 (reserved) BIOS-e820: ffe0 - 0001 (reserved) 0MB HIGHMEM available. 255MB LOWMEM available. On node 0 totalpages: 65534 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 61438 pages, LIFO batch:14 HighMem zone: 0 pages, LIFO batch:1 DMI 2.2 present. ACPI: RSDP (v000 DELL ) @ 0x000fdf50 ACPI: RSDT (v001 DELLGX1 0x0002 ASL 0x0061) @ 0x000fdf64 ACPI: FADT (v001 DELLGX1 0x0002 ASL 0x0061) @ 0x000fdf8c ACPI: DSDT (v001 DELLdt_ex 0x1000 MSFT 0x010b) @ 0x ACPI: PM-Timer IO Port: 0x808 Built 1 zonelists Kernel command line: ro root=/dev/hda3 rhgb acpi=force Initializing CPU#0 PID hash table entries: 1024 (order: 10, 16384 bytes) Detected 598.602 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 255268k/262136k available (2408k kernel code, 6204k reserved, 620k data, 160k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 1187.84 BogoMIPS (lpj=593920) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0383f9ff CPU: After vendor identify, caps: 0383f9ff CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU: After all inits, caps:0383f9ff 0040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: Intel Pentium III (Katmai) stepping 03 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: IRQ9 SCI: Edge set to Level Trigger. checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 202k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfcaee, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040816 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 *10 11 12 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled. ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11 12 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11 12 15) Linux Plug and Play Support v0.97 (c) Adam Belay usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 ACPI: PCI interrupt :00:07.2[D] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 ACPI: PCI interrupt :00:0d.0[A] -> GSI 10 (level, low) -> IRQ 10 ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 ACPI: PCI interrupt :00:0e.0[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI interrupt :00:11.0[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10 ACPI: PCI interrupt :01:00.0[A] -> GSI 10 (level, low) -> IRQ 10 apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) apm: overridden by ACPI. audit: initializing netlink socket (disabled) audit(1121904612.812:0): initialized Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) SELinux: Registering netfilter hooks Initializing Cryptographic API Limiting direct PCI/PCI transfers. pci_hotplug: PCI Hot Plug PCI Core version: 0.5 vesafb: probe of vesafb0 failed with error -6 ACPI: Processor [CPU0] (supports
Re: IRQ routing problem in 2.6.10-rc2
Pierre Ossman wrote: > ** PCI interrupts are no longer routed automatically. If this > ** causes a device to stop working, it is probably because the > ** driver failed to call pci_enable_device(). As a temporary > ** workaround, the "pci=routeirq" argument restores the old > ** behavior. If this argument makes the device work again, > ** please email the output of "lspci" to [EMAIL PROTECTED] > ** so I can fix the driver. If I had just bothered to diff the dmesg:es properly I would have found the problem... Sorry for the noice. Bjorn, the 3c59x driver breaks on this system, but only in one specific slot. lspci -vv included. (The problem is still present on 2.6.12 so I haven't just tried 2.6.10.) Rgds Pierre 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B+ 00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR-
Re: IRQ routing problem in 2.6.10-rc2
Jesper Juhl wrote: > >Have you tried the suggestion given "... As a temporary workaround, >the "pci=routeirq" argument..." ? >You could also try the pci=noacpi boot option to see if that changes anything. > > No, I missed that one. The machine works fine with either of those two options. I sent a comment with lspci to Bjorn Helgaas as suggested. >Also, that's a fairly old kernel you have there, could you try >2.6.13-rc3, 2.6.13-rc3-git6 or 2.6.13-rc3-mm1 ? > > > I discovered the problem running 2.6.12. I only tried these kernels to pinpoint where the problem began. Rgds Pierre - 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] Fix a bit/byte counting error in the MMC/SD code
Richard Purdie wrote: > This fixes what looks like a bit/byte counting error in the MMC/SD code > which was causing data corruption (in the -mm tree). > > Signed-off-by: Richard Purdie <[EMAIL PROTECTED]> Ooops... Must have been late in the evening. Sorry about that blunder. Rgds Pierre - 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] MMC host class
Russell King wrote:
>
>I still don't like the needless duplication. How about doing it this
>way (see the attached patch.)
>
>Note: I also intend to move MMC over to using an IDR for the host
>numbers, which is why we need to setup the name at registration
>time, not allocation time.
>
>
>
This patch should cover the edge case of allocating but not registering
a host.
Rgds
Pierre
diff -uNp linux-2.6.13-rc6/drivers/mmc.orig/mmc.c linux-2.6.13-rc6/drivers/mmc/mmc.c
--- linux-2.6.13-rc6/drivers/mmc.orig/mmc.c 2005-08-08 13:29:53.0 +0200
+++ linux-2.6.13-rc6/drivers/mmc/mmc.c 2005-08-08 13:36:08.0 +0200
@@ -874,7 +874,11 @@ EXPORT_SYMBOL(mmc_remove_host);
void mmc_free_host(struct mmc_host *host)
{
flush_scheduled_work();
- mmc_free_host_sysfs(host);
+
+ if (host->class_dev.class != NULL)
+ mmc_free_host_sysfs(host);
+ else
+ kfree(host);
}
EXPORT_SYMBOL(mmc_free_host);
Re: 8139cp misses interrupts during resume
Pierre Ossman wrote: > Pierre Ossman wrote: > >>I'm having problem with the interrupt getting killed after suspend with >>my 8139cp controller. The problem only appears if the cable is connected >>during resume (before suspend is irrelevant) and the interface is down. >> >>Both suspend-to-disk and suspend-to-ram exhibit the error. dmesg from >>suspend-to-ram included. >> >>I find it a bit strange that 8139cp's interrupt handler isn't included >>when it dumps the handlers. Could this be related to the problem? >> > > > Anyone familiar with this driver that can give me some pointers on what > to look for? I'd prefer not to have to learn how the entire thing works > just to fix one bug. :) > I've gotten a bit close now at least. The problem is that the IRQ handler isn't registered until the device is opened (up:ed) but the hardware triggers interrupt even in a closed state. So either the hardware needs to be silenced or the handler needs to be installed earlier. Rgds Pierre - 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] mmc: Multi-sector writes
Adds support for writing multiple sectors at once. This allows
back-to-back transfers of sectors giving roughly double write throughput.
To be able to detect which sector is causing problems the system falls
back to single sector writes if a failure is detected.
Tested by several people with no side-effects found.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
---
Previously submitted: 2005-03-16
Previously submitted: 2004-12-03
Index: linux-wbsd/drivers/mmc/mmc_block.c
===
--- linux-wbsd/drivers/mmc/mmc_block.c (revision 77)
+++ linux-wbsd/drivers/mmc/mmc_block.c (working copy)
@@ -166,9 +166,25 @@
struct mmc_blk_data *md = mq->data;
struct mmc_card *card = md->queue.card;
int ret;
+
+#ifdef CONFIG_MMC_BULKTRANSFER
+ int failsafe;
+#endif
if (mmc_card_claim_host(card))
goto cmd_err;
+
+#ifdef CONFIG_MMC_BULKTRANSFER
+ /*
+ * We first try transfering multiple blocks. If this fails
+ * we fall back to single block transfers.
+ *
+ * This gives us good performance when all is well and the
+ * possibility to determine which sector fails when all
+ * is not well.
+ */
+ failsafe = 0;
+#endif
do {
struct mmc_blk_request brq;
@@ -189,14 +205,32 @@
brq.stop.arg = 0;
brq.stop.flags = MMC_RSP_R1B;
+#ifdef CONFIG_MMC_BULKTRANSFER
+ /*
+ * A multi-block transfer failed. Falling back to single
+ * blocks.
+ */
+ if (failsafe)
+ brq.data.blocks = 1;
+
+#else
+ /*
+ * Writes are done one sector at a time.
+ */
+ if (rq_data_dir(req) != READ)
+ brq.data.blocks = 1;
+#endif
+
+ ret = 1;
+
if (rq_data_dir(req) == READ) {
brq.cmd.opcode = brq.data.blocks > 1 ? MMC_READ_MULTIPLE_BLOCK : MMC_READ_SINGLE_BLOCK;
brq.data.flags |= MMC_DATA_READ;
} else {
- brq.cmd.opcode = MMC_WRITE_BLOCK;
+ brq.cmd.opcode = brq.data.blocks > 1 ? MMC_WRITE_MULTIPLE_BLOCK :
+MMC_WRITE_BLOCK;
brq.cmd.flags = MMC_RSP_R1B;
brq.data.flags |= MMC_DATA_WRITE;
- brq.data.blocks = 1;
}
brq.mrq.stop = brq.data.blocks > 1 ? &brq.stop : NULL;
@@ -204,19 +238,19 @@
if (brq.cmd.error) {
printk(KERN_ERR "%s: error %d sending read/write command\n",
req->rq_disk->disk_name, brq.cmd.error);
- goto cmd_err;
+ goto cmd_fail;
}
if (brq.data.error) {
printk(KERN_ERR "%s: error %d transferring data\n",
req->rq_disk->disk_name, brq.data.error);
- goto cmd_err;
+ goto cmd_fail;
}
if (brq.stop.error) {
printk(KERN_ERR "%s: error %d sending stop command\n",
req->rq_disk->disk_name, brq.stop.error);
- goto cmd_err;
+ goto cmd_fail;
}
do {
@@ -229,7 +263,7 @@
if (err) {
printk(KERN_ERR "%s: error %d requesting status\n",
req->rq_disk->disk_name, err);
-goto cmd_err;
+goto cmd_fail;
}
} while (!(cmd.resp[0] & R1_READY_FOR_DATA));
@@ -255,6 +289,27 @@
end_that_request_last(req);
}
spin_unlock_irq(&md->lock);
+
+#ifdef CONFIG_MMC_BULKTRANSFER
+ /*
+ * Go back to bulk mode if in failsafe mode.
+ */
+ failsafe = 0;
+#endif
+
+ continue;
+
+ cmd_fail:
+
+#ifdef CONFIG_MMC_BULKTRANSFER
+ if (failsafe)
+ goto cmd_err;
+ else
+ failsafe = 1;
+#else
+ goto cmd_err;
+#endif
+
} while (ret);
mmc_card_release_host(card);
Index: linux-wbsd/drivers/mmc/Kconfig
===
--- linux-wbsd/drivers/mmc/Kconfig (revision 96)
+++ linux-wbsd/drivers/mmc/Kconfig (working copy)
@@ -41,6 +41,15 @@
mount the filesystem. Almost everyone wishing MMC support
should say Y or M here.
+config MMC_BULKTRANSFER
+ bool "Multi-block writes (EXPERIMENTAL)"
+ depends on MMC_BLOCK != n && EXPERIMENTAL
+ default n
+ help
+ By default all writes are done one sector at a time. Enable
+ this option to transfer as large blocks as the host supports.
+ The transfer speed is in most cases doubled.
+
config MMC_ARMMMCI
tristate "ARM AMBA Multimedia Card Interface support"
depends on ARM_AMBA && MMC
Re: Flash erase groups and filesystems
Jörn Engel wrote: >Question came up before, albeit with a different phrasing. One >possible approach to benefit from this ability would be to create a >"forget" operation. When a filesystem already knows that some data is >unneeded (after a truncate or erase operation), it will ask the device >to forget previously occupied blocks. > >The device then has the _option_ of handling the forget operation. >Further reads on these blocks may return random data. > >And since noone stepped up to implement this yet, you can still get >all the fame and glory yourself! ;) > > I'm not sure we're talking about the same thing. I'm not suggesting new features in the VFS layer. I want to know if something breaks if I implement this erase feature in the MMC layer. In essence the file system has marked the sectors as "forget" by issuing a write to them. The question is if it is assumed that they are unchanged if the write fails half-way through. I'd have to say that this is a dangerous assumption to make already today since some systems might not be able to tell where it fails if a large chunk of data is given to it, perhaps because of a deep pipeline before it actually reaches the physical storage. Rgds Pierre - 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: Flash erase groups and filesystems
Jörn Engel wrote: >On Tue, 16 August 2005 20:13:36 +0200, Jörn Engel wrote: > > >>Yes. Most filesystems expect to find either 1) old data or 2) new >>data. Blocks full of 0xff are non-expected. >> >> > >Maybe this isn't obvious. Because of this expectation, it is >absolutely not safe to pre-erase blocks, just because the fs will >write them anyway. Unless you can guarantee that the write will >always succeed, even in case of power outage, you just broke the >expectation. > > > Darn. I suspected as much. I'll guess the erase function will have to be scrapped for now... Whilst we're on the subject, do the filesystems assume that the device can tell them exactly where the write failed? I.e. if the driver knows that 5 sectors were written correctly, but that it failed somewhere beyond that. It might have failed at sector 6, but it might also have failed at sector 10. The assumption that sectors contain either old or new data is still true, we're just unsure which. This can be the case when you feed a controller a lot of data and it can only report back success or failure. >Fixing all filesystem is also not an option, even ignoring the >question whether such a change would be a fix, a change of behaviour >or a plain bug. > >So the only remaining option is to add a new interface that lets >filesystems decide to support pre-erase in some form. And one such >interface would be the "forget" operation. Nice attribute of forget >is the fact that it would also help some FTL layers in the kernel. >There is nothing MMC-specific about it. > > > A bit too much work for me right now. But I'll be there with my erase patch when someone implements it. :) Rgds Pierre - 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] ISA DMA API documentation
randy_dunlap wrote: >+The DMA:able address space is the lowest 16 MB of _physical_ memory. > The DMA-able >+Also the transfer block may not cross page boundaries (which are 64k). > I would write:(which are 64 KB). > >if I knew that was correct, but I don't. >Does Linux limit all ISA-DMA to not crossing 64 KB boundaries? >I haven't looked at the code yet, just PC-AT Technical Reference, >which says that DMA controller 1 is limited to 8-bit transfers and >64 KB blocks and DMA controller 2 is limited to 16-bit data transfers >and 128 KB boundaries. >Does i386-compatible and later chipsets or LPC change/affect this? >(I see that you cover 8/16-bit transfers later in the doc.) > > Sorry, my bad. 128k is quite correct for 16-bit data transfers. I've just been using 8-bit transfers so I got a bit too familiar with just those. :) >+To translate the virtual address to a physical use the normal DMA >+API. Do _not_ use isa_virt_to_phys() even though it does the same >+thing. The reason for this is that you will get a requirement to ISA >+(instead of only ISA_DMA_API). > >I don't understand what you are trying to say in: >... is that you will get a requirement to ISA >Oh, it's Kconfig-related, right? So maybe: >"... is that you will get a config requirement for ISA..." ? > > > Yes, that's what I'm trying to say. I'll try to make it clearer. Thanks for the feedback. I'll get your suggestions in and post a new patch. Rgds Pierre - 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] ISA DMA API documentation
Documentation for how the ISA DMA controller is handled in the kernel. Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]> New version after feedback from Randy Dunlap. Index: linux-wbsd/Documentation/DMA-ISA-LPC.txt === --- linux-wbsd/Documentation/DMA-ISA-LPC.txt (revision 0) +++ linux-wbsd/Documentation/DMA-ISA-LPC.txt (revision 0) @@ -0,0 +1,151 @@ +DMA with ISA and LPC devices + + + Pierre Ossman <[EMAIL PROTECTED]> + +This document describes how to do DMA transfers using the old ISA DMA +controller. Even though ISA is more or less dead today the LPC bus +uses the same DMA system so it will be around for quite some time. + +Part I - Headers and dependencies +- + +To do ISA style DMA you need to include two headers: + +#include +#include + +The first is the generic DMA API used to convert virtual addresses to +physical addresses (see Documentation/DMA-API.txt for details). + +The second contains the routines specific to ISA DMA transfers. Since +this is not present on all platforms make sure you construct your +Kconfig to be dependent on ISA_DMA_API (not ISA) so that nobody tries +to build your driver on unsupported platforms. + +Part II - Buffer allocation +--- + +The ISA DMA controller has some very strict requirements on which +memory it can access so extra care must be taken when allocating +buffers. + +(You usually need a special buffer for DMA transfers instead of +transferring directly to and from your normal data structures.) + +The DMA-able address space is the lowest 16 MB of _physical_ memory. +Also the transfer block may not cross page boundaries (which are 64 +or 128 KiB depending on which channel you use). + +In order to allocate a piece of memory that satisfies all these +requirements you pass the flag GFP_DMA to kmalloc. + +Unfortunately the memory available for ISA DMA is scarce so unless you +allocate the memory during boot-up it's a good idea to also pass +__GFP_REPEAT and __GFP_NOWARN to make the allocater try a bit harder. + +(This scarcity also means that you should allocate the buffer as +early as possible and not release it until the driver is unloaded.) + +Part III - Address translation +-- + +To translate the virtual address to a physical use the normal DMA +API. Do _not_ use isa_virt_to_phys() even though it does the same +thing. The reason for this is that the function isa_virt_to_phys() +will require a Kconfig dependency to ISA, not just ISA_DMA_API which +is really all you need. Remember that even though the DMA controller +has its origins in ISA it is used elsewhere. + +Note: x86_64 had a broken DMA API when it came to ISA but has since +been fixed. If your arch has problems then fix the DMA API instead of +reverting to the ISA functions. + +Part IV - Channels +-- + +A normal ISA DMA controller has 8 channels. The lower four are for +8-bit transfers and the upper four are for 16-bit transfers. + +(Actually the DMA controller is really two separate controllers where +channel 4 is used to give DMA access for the second controller (0-3). +This means that of the four 16-bits channels only three are usable.) + +You allocate these in a similar fashion as all basic resources: + +extern int request_dma(unsigned int dmanr, const char * device_id); +extern void free_dma(unsigned int dmanr); + +The ability to use 16-bit or 8-bit transfers is _not_ up to you as a +driver author but depends on what the hardware supports. Check your +specs or test different channels. + +Part V - Transfer data +-- + +Now for the good stuff, the actual DMA transfer. :) + +Before you use any ISA DMA routines you need to claim the DMA lock +using claim_dma_lock(). The reason is that some DMA operations are +not atomic so only one driver may fiddle with the registers at a +time. + +The first time you use the DMA controller you should call +clear_dma_ff(). This clears an internal register in the DMA +controller that is used for the non-atomic operations. As long as you +(and everyone else) uses the locking functions then you only need to +reset this once. + +Next, you tell the controller in which direction you intend to do the +transfer using set_dma_mode(). Currently you have the options +DMA_MODE_READ and DMA_MODE_WRITE. + +Set the address from where the transfer should start (this needs to +be 16-bit aligned for 16-bit transfers) and how many bytes to +transfer. Note that it's _bytes_. The DMA routines will do all the +required translation to values that the DMA controller understands. + +The final step is enabling the DMA channel and releasing the DMA +lock. + +Once the DMA transfer is finished (or timed out) you should disable +the channel again. You should also check get_dma_residue() to make +sure
Kernel panic with dc395x in 2.6.12.2
I upgraded a machine from 2.6.11.7 to 2.6.12.2 today and the only thanks I got was a brand new kernel panic. From the backtrace it seems that the dc395x driver is the culprit. From what I can tell it hasn't undergone any changes between the two versions. Image of kernel panic: http://craffe.se/img_0041.jpg dmesg from 2.6.11.7 included. Rgds Pierre Linux version 2.6.11.7 ([EMAIL PROTECTED]) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)) #1 SMP Sun Apr 17 02:15:56 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3fffc000 (usable) BIOS-e820: 3fffc000 - 3000 (ACPI data) BIOS-e820: 3000 - 4000 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. On node 0 totalpages: 262140 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:16 HighMem zone: 32764 pages, LIFO batch:7 DMI 2.3 present. Using APIC driver default ACPI: RSDP (v000 ASUS ) @ 0x000f5850 ACPI: RSDT (v001 ASUS P4S800 0x42302e31 MSFT 0x31313031) @ 0x3fffc000 ACPI: FADT (v001 ASUS P4S800 0x42302e31 MSFT 0x31313031) @ 0x3fffc0c0 ACPI: BOOT (v001 ASUS P4S800 0x42302e31 MSFT 0x31313031) @ 0x3fffc030 ACPI: MADT (v001 ASUS P4S800 0x42302e31 MSFT 0x31313031) @ 0x3fffc058 ACPI: DSDT (v001 ASUS P4S800 0x1000 MSFT 0x010b) @ 0x ACPI: PM-Timer IO Port: 0xe408 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:2 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 15:2 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) Allocating PCI resources starting at 4000 (gap: 4000:bec0) Built 1 zonelists Kernel command line: ro root=LABEL=/ rhgb quiet acpi=ht Found and enabled local APIC! mapped APIC to d000 (fee0) Initializing CPU#0 CPU 0 irqstacks, hard=c0449000 soft=c0429000 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 2400.368 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1033508k/1048560k available (2226k kernel code, 14332k reserved, 744k data, 240k init, 131056k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 4751.36 BogoMIPS (lpj=2375680) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: bfebfbff 4400 CPU: After vendor identify, caps: bfebfbff 4400 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 0 CPU: After all inits, caps: bfebfbff 0080 4400 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU0: Thermal monitoring enabled Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel(R) Pentium(R) 4 CPU 2.40GHz stepping 09 per-CPU timeslice cutoff: 1463.01 usecs. task migration cache decay timeout: 2 msecs. Booting processor 1/1 eip 3000 CPU 1 irqstacks, hard=c044a000 soft=c042a000 Initializing CPU#1 Calibrating delay loop... 4784.12 BogoMIPS (lpj=2392064) CPU: After generic identify, caps: bfebfbff 4400 CPU: After vendor identify, caps: bfebfbff 4400 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 0 CPU: After all inits, caps: bfebfbff 0080 4400 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: Intel P4/Xeon Extended MCE MSRs (12) available CPU1: Thermal monitoring enabled CPU1: Intel(R) Pentium(R) 4 CPU 2.40GHz stepping 09 Total of 2 processors activated (9535.48 BogoMIPS). checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs CPU0 attaching sched-domain: domain 0: span 0003 groups: 0001 0002 domain 1: span 0003 groups: 0003 CPU1 attaching sch
Re: [PATCH] 8139cp - redetect link after suspend
John W. Linville wrote: >On Mon, Jul 04, 2005 at 12:22:53AM +0200, Pierre Ossman wrote: > > >>After suspend the driver needs to retest link status in case the cable >>has been inserted or removed during the suspend. >> >>Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]> >> >> > >Please copy netdev@vger.kernel.org for network driver patches. > >Other than that, the patch looks acceptable to me, fwiw... > > Has anyone had else had the time to review this? Jeff especially. Rgds Pierre - 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: 8139cp misses interrupts during resume
Pierre Ossman wrote: > I'm having problem with the interrupt getting killed after suspend with > my 8139cp controller. The problem only appears if the cable is connected > during resume (before suspend is irrelevant) and the interface is down. > > Both suspend-to-disk and suspend-to-ram exhibit the error. dmesg from > suspend-to-ram included. > > I find it a bit strange that 8139cp's interrupt handler isn't included > when it dumps the handlers. Could this be related to the problem? > Anyone familiar with this driver that can give me some pointers on what to look for? I'd prefer not to have to learn how the entire thing works just to fix one bug. :) Rgds Pierre - 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] mmc: Multi-sector writes
Andrew Morton wrote: >The fact that this is enabled under the experimental >CONFIG_MMC_BULKTRANSFER seems unfortunate. I mean, if the code works OK >then we should just enable it unconditionally, no? > > > It was made this way to make Russell more open to it. I have since not recieved any more comments from him so I figured I could pass it by you instead to get more wide spread testing. The long term goal was removing the config and having it on all the time. >I'm thinking that it would be better to not have the config option there >and then re-add it late in the 2.6.14 cycle if someone reports problems >which cannot be fixed. Or at least make it default to 'y' so we get more >testing coverage, then remove the config option later. Or something. > >Thoughts? > > Removing it would be preferable by me. All that #ifdef tends to clutter up the code. After som initial problem with a buggy card everything has worked flawlesly. Rgds Pierre - 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] mmc: Multi-sector writes
Russell King wrote: > >I'd rather not. The problem is that we have a host (thanks Intel) >which is unable to report how many bytes were transferred before an >error occurs. My fear is that doing anything other than sector by >sector write will lead to corruption should an error occur. > >However, I've no way to induce such an error, so I can only base >this on theory. > >It may work perfectly for the case when everything's operating >correctly, but I suspect if you're going to do multi-sector writes, >it'll all fall apart on the first error, especially on this host. > > > We had this discussion on LKML and Alan Cox' comment on it was that a solution like this would be acceptable, where we try and shove everything out first and then fall back on sector-by-sector to determine where an error occurs. This will only break if the problematic sector keeps shifting around, but at that point the card is probably toast anyway (if the thing keeps moving how can you bad block it?). Rgds Pierre - 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] mmc: Multi-sector writes
Russell King wrote: >On Thu, Aug 18, 2005 at 09:26:03AM +0200, Pierre Ossman wrote: > > >>We had this discussion on LKML and Alan Cox' comment on it was that a >>solution like this would be acceptable, where we try and shove >>everything out first and then fall back on sector-by-sector to determine >>where an error occurs. This will only break if the problematic sector >>keeps shifting around, but at that point the card is probably toast >>anyway (if the thing keeps moving how can you bad block it?). >> >> > >There are two different kinds of error - the ones at the transport >level which we are able to force a result of "no sectors transferred" >for. For all other errors and successful completions, the driver >reports "all sectors tranferred" since the driver level doesn't know >that an error occurred. > >This causes us to tell the upper levels that we were successful, >even if we weren't. Hence the problem. > > > I still don't understand where you see the problem. As you said there are two problems that can occur: * Transport problem. The driver will report back a CRC error, timeout or whatnot and break. We might not know how many sectors survived so we try again, going sector-by-sector. We might get a transfer error again, possibly even before the previous one. But at this point the transport is probably so noisy that we have little chans of doing a clean umount anyway. So when the device gets fixed, either by replaying the journal or doing a fsck, it would have been in the same state if we would have been able to tell exactly which sectors got written. * Media error. If the card fails to write data to flash then it will set the corresponding bits in the status register. We do not check these ATM so any errors there will get overlooked. So I fail to see how this would be different when writing several sectors at once. If we implement this check we will not know where the card failed its write, but again we fall back to sector-by-sector in this case to determine exactly where the card has problems. Rgds Pierre - 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] mmc: Multi-sector writes
Alan Cox wrote: >On Iau, 2005-08-18 at 09:26 +0200, Pierre Ossman wrote: > > >>everything out first and then fall back on sector-by-sector to determine >>where an error occurs. This will only break if the problematic sector >>keeps shifting around, but at that point the card is probably toast >>anyway (if the thing keeps moving how can you bad block it?). >> >> > >Providing the sectors are not finally completed to higher levels until >they are written that works fine. > I don't think there's any risk of that. What _might_ happen is that more data gets written to disk than is reported to the upper layers because of these buffering issues. Rgds Pierre - 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] mmc: Multi-sector writes
Pavel Machek wrote: >>* Transport problem. The driver will report back a CRC error, timeout or >>whatnot and break. We might not know how many sectors survived so we try >>again, going sector-by-sector. We might get a transfer error again, >>possibly even before the previous one. But at this point the transport >>is probably so noisy that we have little chans of doing a clean umount >>anyway. So when the device gets fixed, either by replaying the journal >> >> > >Well, but then you can get: > >good data #1 >trash #2 >good data #2 >trash #1 > >I'm not sure how much journalling filesystems will like that in their >journals... > > > Unless the card is horribly broken it will not write sectors that cannot be transfered successfully. If there would be a transport error that goes undetected by the CRC we would just continue, believing that everything is peachy. The scenario you're describing could show up in the case of a media error though. But that would mean that a sector went bad in an extremely short time, which isn't likely unless the wear leveling has gone crazy or the card is completely worn out. Either way the card is no longer useful. Rgds Pierre - 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] MMC host class
Russell King wrote: > >Hmm, I think I've gone back to preferring something similar to your >original approach actually. I've also included the IDR patch. > > > Ok. Just as long as it works. :) My two concerns are: * Things that assume there's a name for every kobject. * Things that assume that a kobject's name cannot change. The documentation isn't clear about the semantics in these cases. But you have more experience with kobjects than I do so perhaps these are obvious to you. Otherwise I'm just waiting to see this committed. Rgds Pierre - 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] mmc: Multi-sector writes
Pavel Machek wrote: > >Maybe the card is pretty close to going to crash, but... two disk >successive disk errors still should not be cause for journal >corruption. > >[Also errors could be corelated. Imagine severe overheat. You'll >successive failing writes, but if you let cool it down, you'll still >have working media... only with corrupt journal :-)] > Pavel > > Hmm... So how is this handled in other systems? E.g. if you yank a USB device whilst there is a lot of outstanding data inside the device that hasn't been ack:d yet. The way I see it, filesystems should assume the following at a failed write: * 0-n sectors were written successfully. * 0-1 sectors have corrupt data. * 0-m sectors have old data. * The lower layer will report back 0-k successfully written sectors, where k <= n. So perhaps the best course of action is to remove the sector-by-sector failsafe? It will increase the chance of k < n, but it will not break above assumption. Rgds Pierre - 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 patch] fs/adfs/adfs.h: "extern inline" doesn't make sense
Adrian Bunk wrote: > [ this time with a better subject ] > > "extern inline" doesn't make sense. > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > Isn't 'extern inline' an old gcc trick to force inlining? (instead of just hinting) - 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 1/2] ios for mmc chip select
Adds a new ios for setting the chip select pin on MMC cards. Needed on
SD controllers which use this pin for other things and therefore cannot
have it pulled high at all times.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Index: linux/drivers/mmc/mmc.c
===
--- linux/drivers/mmc/mmc.c (revision 151)
+++ linux/drivers/mmc/mmc.c (working copy)
@@ -457,6 +457,11 @@
{
struct mmc_command cmd;
+ host->ios.chip_select = MMC_CS_HIGH;
+ host->ops->set_ios(host, &host->ios);
+
+ mmc_delay(1);
+
cmd.opcode = MMC_GO_IDLE_STATE;
cmd.arg = 0;
cmd.flags = MMC_RSP_NONE;
@@ -464,6 +469,11 @@
mmc_wait_for_cmd(host, &cmd, 0);
mmc_delay(1);
+
+ host->ios.chip_select = MMC_CS_DONTCARE;
+ host->ops->set_ios(host, &host->ios);
+
+ mmc_delay(1);
}
/*
@@ -475,6 +485,7 @@
host->ios.vdd = bit;
host->ios.bus_mode = MMC_BUSMODE_OPENDRAIN;
+ host->ios.chip_select = MMC_CS_DONTCARE;
host->ios.power_mode = MMC_POWER_UP;
host->ops->set_ios(host, &host->ios);
@@ -492,6 +503,7 @@
host->ios.clock = 0;
host->ios.vdd = 0;
host->ios.bus_mode = MMC_BUSMODE_OPENDRAIN;
+ host->ios.chip_select = MMC_CS_DONTCARE;
host->ios.power_mode = MMC_POWER_OFF;
host->ops->set_ios(host, &host->ios);
}
Index: linux/include/linux/mmc/host.h
===
--- linux/include/linux/mmc/host.h (revision 151)
+++ linux/include/linux/mmc/host.h (working copy)
@@ -46,6 +46,12 @@
#define MMC_BUSMODE_OPENDRAIN 1
#define MMC_BUSMODE_PUSHPULL 2
+ unsigned char chip_select; /* SPI chip select */
+
+#define MMC_CS_DONTCARE 0
+#define MMC_CS_HIGH 1
+#define MMC_CS_LOW 2
+
unsigned char power_mode; /* power supply mode */
#define MMC_POWER_OFF 0
[PATCH 2/2] support for mmc chip select in wbsd
Use the chip select ios in the wbsd driver.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Index: linux/drivers/mmc/wbsd.c
===
--- linux/drivers/mmc/wbsd.c (revision 161)
+++ linux/drivers/mmc/wbsd.c (working copy)
@@ -42,7 +42,7 @@
#include "wbsd.h"
#define DRIVER_NAME "wbsd"
-#define DRIVER_VERSION "1.3"
+#define DRIVER_VERSION "1.4"
#ifdef CONFIG_MMC_DEBUG
#define DBG(x...) \
@@ -960,8 +960,9 @@
struct wbsd_host* host = mmc_priv(mmc);
u8 clk, setup, pwr;
- DBGF("clock %uHz busmode %u powermode %u Vdd %u\n",
- ios->clock, ios->bus_mode, ios->power_mode, ios->vdd);
+ DBGF("clock %uHz busmode %u powermode %u cs %u Vdd %u\n",
+ ios->clock, ios->bus_mode, ios->power_mode, ios->chip_select,
+ ios->vdd);
spin_lock_bh(&host->lock);
@@ -1003,13 +1004,11 @@
/*
* MMC cards need to have pin 1 high during init.
- * Init time corresponds rather nicely with the bus mode.
* It wreaks havoc with the card detection though so
- * that needs to be disabed.
+ * that needs to be disabled.
*/
setup = wbsd_read_index(host, WBSD_IDX_SETUP);
- if ((ios->power_mode == MMC_POWER_ON) &&
- (ios->bus_mode == MMC_BUSMODE_OPENDRAIN))
+ if (ios->chip_select == MMC_CS_HIGH)
{
setup |= WBSD_DAT3_H;
host->flags |= WBSD_FIGNORE_DETECT;
@@ -1017,7 +1016,12 @@
else
{
setup &= ~WBSD_DAT3_H;
- host->flags &= ~WBSD_FIGNORE_DETECT;
+
+ /*
+ * We cannot resume card detection immediatly
+ * because of capacitance and delays in the chip.
+ */
+ mod_timer(&host->ignore_timer, jiffies + HZ/100);
}
wbsd_write_index(host, WBSD_IDX_SETUP, setup);
@@ -1036,6 +1040,31 @@
\*/
/*
+ * Helper function to reset detection ignore
+ */
+
+static void wbsd_reset_ignore(unsigned long data)
+{
+ struct wbsd_host *host = (struct wbsd_host*)data;
+
+ BUG_ON(host == NULL);
+
+ DBG("Resetting card detection ignore\n");
+
+ spin_lock_bh(&host->lock);
+
+ host->flags &= ~WBSD_FIGNORE_DETECT;
+
+ /*
+ * Card status might have changed during the
+ * blackout.
+ */
+ tasklet_schedule(&host->card_tasklet);
+
+ spin_unlock_bh(&host->lock);
+}
+
+/*
* Helper function for card detection
*/
static void wbsd_detect_card(unsigned long data)
@@ -1097,7 +1126,7 @@
* Delay card detection to allow electrical connections
* to stabilise.
*/
- mod_timer(&host->timer, jiffies + HZ/2);
+ mod_timer(&host->detect_timer, jiffies + HZ/2);
}
spin_unlock(&host->lock);
@@ -1124,6 +1153,8 @@
mmc_detect_change(host->mmc);
}
+ else
+ spin_unlock(&host->lock);
}
static void wbsd_tasklet_fifo(unsigned long param)
@@ -1328,11 +1359,15 @@
spin_lock_init(&host->lock);
/*
- * Set up detection timer
+ * Set up timers
*/
- init_timer(&host->timer);
- host->timer.data = (unsigned long)host;
- host->timer.function = wbsd_detect_card;
+ init_timer(&host->detect_timer);
+ host->detect_timer.data = (unsigned long)host;
+ host->detect_timer.function = wbsd_detect_card;
+
+ init_timer(&host->ignore_timer);
+ host->ignore_timer.data = (unsigned long)host;
+ host->ignore_timer.function = wbsd_reset_ignore;
/*
* Maximum number of segments. Worst case is one sector per segment
@@ -1370,7 +1405,8 @@
host = mmc_priv(mmc);
BUG_ON(host == NULL);
- del_timer_sync(&host->timer);
+ del_timer_sync(&host->ignore_timer);
+ del_timer_sync(&host->detect_timer);
mmc_free_host(mmc);
Index: linux/drivers/mmc/wbsd.h
===
--- linux/drivers/mmc/wbsd.h (revision 161)
+++ linux/drivers/mmc/wbsd.h (working copy)
@@ -181,5 +181,6 @@
struct tasklet_struct finish_tasklet;
struct tasklet_struct block_tasklet;
- struct timer_list timer; /* Card detection timer */
+ struct timer_list detect_timer; /* Card detection timer */
+ struct timer_list ignore_timer; /* Ignore detection timer */
};
[PATCH] mmc: conditional scr sysfs entry
Only show the scr file in sysfs for SD cards. Previously this was
present for all cards but had a contents of 0 for MMC cards.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Index: linux-wbsd/drivers/mmc/mmc_sysfs.c
===
--- linux-wbsd/drivers/mmc/mmc_sysfs.c (revision 157)
+++ linux-wbsd/drivers/mmc/mmc_sysfs.c (working copy)
@@ -46,7 +46,6 @@
static struct device_attribute mmc_dev_attrs[] = {
MMC_ATTR_RO(cid),
MMC_ATTR_RO(csd),
- MMC_ATTR_RO(scr),
MMC_ATTR_RO(date),
MMC_ATTR_RO(fwrev),
MMC_ATTR_RO(hwrev),
@@ -57,6 +56,8 @@
__ATTR_NULL
};
+static struct device_attribute mmc_dev_attr_scr = MMC_ATTR_RO(scr);
+
static void mmc_release_card(struct device *dev)
{
@@ -207,10 +208,20 @@
*/
int mmc_register_card(struct mmc_card *card)
{
+ int ret;
+
snprintf(card->dev.bus_id, sizeof(card->dev.bus_id),
"%s:%04x", card->host->host_name, card->rca);
- return device_add(&card->dev);
+ ret = device_add(&card->dev);
+ if (ret == 0) {
+ if (mmc_card_sd(card)) {
+ ret = device_create_file(&card->dev, &mmc_dev_attr_scr);
+ if (ret)
+device_del(&card->dev);
+ }
+ }
+ return ret;
}
/*
@@ -219,8 +230,12 @@
*/
void mmc_remove_card(struct mmc_card *card)
{
- if (mmc_card_present(card))
+ if (mmc_card_present(card)) {
+ if (mmc_card_sd(card))
+ device_remove_file(&card->dev, &mmc_dev_attr_scr);
+
device_del(&card->dev);
+ }
put_device(&card->dev);
}
Re: reboot vs poweroff (was: Linux 2.6.13)
Meelis Roos wrote: > > It's OK then - I'm not using any suspend and I had a problem that my > machine powered down instead of reboot. The patch that went into 2.6.13 > after rc7 fixed it for me. So the current tree is OK for me and if it's > OK for you too after suspend2 changes then this case can probably be > closed. > I'm still having problems with this patch. Both swsusp and swsusp2 are affected. Perhaps the fix Nigel did needs to be done to swsusp aswell? Bugzilla entry: http://bugme.osdl.org/show_bug.cgi?id=4320 Rgds Pierre - 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: reboot vs poweroff
Eric W. Biederman wrote: >Hmm. Looking at that bug report it specifies 2.6.11. Does this >problem really happen in 2.6.13? > > > I first noticed it in 2.6.11. It was fixed sometime during 2.6.13-rc only to be killed of again in 2.6.13-rc7. The bugzilla now has a patch for 2.6.13 which fixes the problem again. Rgds Pierre - 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: reboot vs poweroff
Eric W. Biederman wrote: >Thanks. > >This is clearly a code path I missed when I was fixing things. > >When I made the final acpi change I checked for any other users >of device_suspend and it seems I was blind and missed this one. >Looking again... > >The patch in the bug report looks correct. However it is still >a little incomplete. In particular the reboot notifier is not >being called, and since not everything has been converted into >using shutdown methods that could lead to some other inconsistent >behavior. > >Does anyone have any problems with the patch below? >If not I will send this off to Linus.. > > > Patch tested and works fine here. You should probably make a note in the bugzilla so we don't get a conflicting merge from the ACPI folks. I suppose Nigel should use this function in swsusp2 aswell? Rgds Pierre - 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] 8139cp: Catch all interrupts
Register interrupt handler when net device is registered. Avoids missing interrupts if the interrupt mask gets out of sync. Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]> --- The reason this patch is needed for me is that the resume function is broken. It enables interrupts unconditionally, but the interrupt handler is only registered when the device is up. I don't have enough knowledge about the driver to fix the resume function so this patch will instead make sure that the interrupt handler is registered at all times (which can be a nice safeguard even when the resume function gets fixed). Index: linux-wbsd/drivers/net/8139cp.c === --- linux-wbsd/drivers/net/8139cp.c (revision 165) +++ linux-wbsd/drivers/net/8139cp.c (working copy) @@ -1204,20 +1204,11 @@ cp_init_hw(cp); - rc = request_irq(dev->irq, cp_interrupt, SA_SHIRQ, dev->name, dev); - if (rc) - goto err_out_hw; - netif_carrier_off(dev); mii_check_media(&cp->mii_if, netif_msg_link(cp), TRUE); netif_start_queue(dev); return 0; - -err_out_hw: - cp_stop_hw(cp); - cp_free_rings(cp); - return rc; } static int cp_close (struct net_device *dev) @@ -1238,7 +1229,6 @@ spin_unlock_irqrestore(&cp->lock, flags); synchronize_irq(dev->irq); - free_irq(dev->irq, dev); cp_free_rings(cp); return 0; @@ -1813,6 +1803,10 @@ if (rc) goto err_out_iomap; + rc = request_irq(dev->irq, cp_interrupt, SA_SHIRQ, dev->name, dev); + if (rc) + goto err_out_unreg; + printk (KERN_INFO "%s: RTL-8139C+ at 0x%lx, " "%02x:%02x:%02x:%02x:%02x:%02x, " "IRQ %d\n", @@ -1832,6 +1826,8 @@ return 0; +err_out_unreg: + unregister_netdev(dev); err_out_iomap: iounmap(regs); err_out_res: @@ -1852,6 +1848,7 @@ if (!dev) BUG(); + free_irq(dev->irq, dev); unregister_netdev(dev); iounmap(cp->regs); if (cp->wol_enabled) pci_set_power_state (pdev, PCI_D0);
Re: [PATCH] ISA DMA suspend for i386
Jeff Garzik wrote: > > Where is CONFIG_PM? > > Jeff I'm not sure you're receiving my mails, but I'll give it a try anyway. It would also seem that my MTA is choking on your MX entries. I'll look into that once I get home. CONFIG_PM is missing because of consistency with i8259.c, on which the code is based. So if it is desired I suppose a patch for them both would be in order. Rgds Pierre - 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/
swsusp doesn't suspend devices
It would seem that swsusp doesn't properly suspend devices, or more
precisely it wakes them up again before suspending the machine.
The problem is in swsusp_suspend(). It is designed as if
swsusp_arch_suspend() would suspend the hardware, when in fact all it
does is prepare for a suspend. The effect is that devices are brought
back up because swsusp_suspend() believes it is resuming.
Below is a patch that uses the same system as kernel/power/disk.c to
determine if it's suspending or resuming. The patch brings up a new
problem though, disk writes generate a huge amount of "scheduling while
atomic".
---
Index: linux-wbsd/kernel/power/swsusp.c
===
--- linux-wbsd/kernel/power/swsusp.c(revision 165)
+++ linux-wbsd/kernel/power/swsusp.c(working copy)
@@ -84,6 +84,8 @@
/* Local variables that should not be affected by save */
static unsigned int nr_copy_pages __nosavedata = 0;
+static int in_suspend __nosavedata = 0;
+
/* Suspend pagedir is allocated before final copy, therefore it
must be freed after resume
@@ -897,15 +899,18 @@
return error;
}
+ in_suspend = 1;
save_processor_state();
if ((error = swsusp_arch_suspend()))
printk("Error %d suspending\n", error);
- /* Restore control flow magically appears here */
- restore_processor_state();
- BUG_ON (nr_copy_pages_check != nr_copy_pages);
- restore_highmem();
- device_power_up();
- local_irq_enable();
+ if (!in_suspend || error) {
+ /* Restore control flow magically appears here */
+ restore_processor_state();
+ BUG_ON (nr_copy_pages_check != nr_copy_pages);
+ restore_highmem();
+ device_power_up();
+ local_irq_enable();
+ }
return error;
}
-
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: swsusp doesn't suspend devices
Rafael J. Wysocki wrote: >On Wednesday, 7 of September 2005 13:20, Pierre Ossman wrote: > > >>It would seem that swsusp doesn't properly suspend devices, or more >>precisely it wakes them up again before suspending the machine. >> >> > >Yes, it does. By design. > > > That seems counter-productive, so I'm obviously missing something. - 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] mmc: Handle suspend/resume in Ricoh MMC disabler
On Sat, 29 Dec 2007 00:11:42 -0800 Philip Langdale <[EMAIL PROTECTED]> wrote: > As pci config space is reinitialised on a suspend/resume cycle, the > disabler needs to work its magic at resume time. For symmetry this > change also explicitly enables the controller at suspend time but > it's not strictly necessary. > > Signed-off-by: Philipl Langdale <[EMAIL PROTECTED]> > Thanks applied. Your patch was a bit borked though (a bunch of extra spaces). You should have a look at that for future patches. Rgds Pierre signature.asc Description: PGP signature
Re: [patch] split MMC_CAP_4_BIT_DATA
On Tue, 8 Jan 2008 13:29:39 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > The on-chip Blackfin MMC/SD/SDIO host controller has the ability to do 1-bit > MMC, 1-bit/4-bit SD, and 1-bit/4-bit SDIO. Thus the current convention of > MMC_CAP_4_BIT_DATA meaning "your host controller can do 1-bit or 4-bit for all > modes" is insufficient for our needs. The attached patch splits > MMC_CAP_4_BIT_DATA into MMC_CAP_MMC_4_BIT_DATA and MMC_CAP_SD_4_BIT_DATA and > updates all host controllers to include these in their caps and then changes > existing code to check the new defines. At the moment, SD/SDIO are lumped > into MMC_CAP_SD_4_BIT_DATA ... should I bother with splitting that into SD and > SDIO as well while I'm doing this ? > > Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]> I fail to see why you need to split MMC and SD. Could you elaborate why the controller won't work with MMC cards? I haven't seen any differences from SD. 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: Replacing drivers/mmc directory in kerenl 2.6.22.1 with drivers/mmc in kernel 2.6.23.1
On Sun, 6 Jan 2008 20:02:46 -0800 "raki john" <[EMAIL PROTECTED]> wrote: > > Can I replace drivers/mmc directory in 2.6.22.1 with drivers/mmc > directory in 2.6.23.1. Does this cause any issues. Is there any code > in drivers/mmc in 2.6.23.1 which depends on other features in kernel > 2.6.23.1. > I'm afraid I've not kept track of such things. Try it and see if it compiles. Rgds Pierre signature.asc Description: PGP signature
Re: Crash in Kernel 2.6.22.1 after calling mmc_register_card
On Mon, 7 Jan 2008 15:31:32 -0800 "raki john" <[EMAIL PROTECTED]> wrote: > Hi All, > > Please CC me on responses. > > I am working on a SD/MMC Host driver . > > I am getting kerenl oops after mmc_register_card () is called. > i working on LINUX 2.6.22.1 kerenl. > > What might be the reason for this. > That's a rather central place for it to crash, so I'm doubtful it's a bug there. I'd guess some kind of memory corruption (an all to easy mistake to make when writing a new driver). Are you using DMA for the controller? If so, try using PIO and see if it stops oopsing. Rgds Pierre signature.asc Description: PGP signature
Re: [patch] split MMC_CAP_4_BIT_DATA
On Tue, 8 Jan 2008 14:40:49 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > > i dont understand what's confusing. the Blackfin on chip host controller > only > supports 1-bit MMC, but it supports 4-bit SD/SDIO. this is a fact. while it > may be a stupid decision, it is what it is, and i need the framework made > more flexible in order to get the Blackfin driver merged cleanly. we do > software for hardware, we dont do hardware. Well, since I've seen no _hardware_ differences between 4-bit MMC and 4-bit SD, "support" in this case must me "vendor will guarantee it works". And that is not the kind of "support" that needs a distinction in the code. So, again, if you feel that there is a hardware difference between 4-bit MMC and 4-bit SD then please elaborate as it is my understanding that they are identical. 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] split MMC_CAP_4_BIT_DATA
On Wed, 9 Jan 2008 11:21:40 +0800 "Cai, Cliff" <[EMAIL PROTECTED]> wrote: > > Hi,all > > I'd like to say something about this issue. > Currently,the blackfin on chip SD host ONLY support 1-bit MMC while > support 1-bit/4-bit SD/SDIO. > And we want our driver to support both 1-bit MMC and 4-bit SD/SDIO.but > the current MMC driver framework > Only allow us to set one kind of bus width,either 1-bit or 4-bit.So in > order to meet our case,we need more flexible mechanism > To inform the upper commom driver to know our situation. > That's just iterating what's already been said. My claim is that 4-bit is 4-bit, regardless if it's MMC or SD. So if you want this patch to go in you need to explain why there is a difference for the blackfin controller. 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] split MMC_CAP_4_BIT_DATA
On Tue, 8 Jan 2008 16:44:08 -0500 "Mike Frysinger" <[EMAIL PROTECTED]> wrote: > On Jan 8, 2008 3:49 PM, Pierre Ossman <[EMAIL PROTECTED]> wrote: > > So, again, if you feel that there is a hardware difference between 4-bit > > MMC and 4-bit SD then please elaborate as it is my understanding that they > > are identical. > > you may be 100% correct, i have no idea, i'm not really familiar with > MMC/SD/SDIO at all. The patch adds complexity to the system. So until you can convince me that complexity is actually needed, I'm afraid the answer is NAK. 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: lba 28-bit addressing mode for MMC/SD card
On Thu, 27 Dec 2007 05:51:46 -0800 (PST) Sandeep K <[EMAIL PROTECTED]> wrote: > Hi all, > > does the linux kernel MMC block layer supports lba > 28-bit > addressing mode for MMC/SD card ? > LBA is not a term used for MMC/SD, so I'm unsure what you're referring to. The MMC layer supports legacy cards, SDHC and MMC 4.2 addressing. All addresses are 32-bit. 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: 2.6.24-rc6: ricoh_mmc woes
On Sat, 05 Jan 2008 21:28:50 +0100 Harald Dunkel <[EMAIL PROTECTED]> wrote: > Hi folks, > > I've got a problem with a Ricoh mmc reader. As soon as I insert a > sd card I get tons of I/O errors. syslog says: > You're getting some kind of bus transfer error. Did this work with 2.6.23? Please enable CONFIG_MMC_DEBUG and include a copy of the output of dmesg. 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] split MMC_CAP_4_BIT_DATA
On Thu, 10 Jan 2008 00:45:27 +0800 "Bryan Wu" <[EMAIL PROTECTED]> wrote: > > Actually, Blackfin BF54x on-chip SDIO host controller is supposed to > support 1-bit and 4-bit MMC or SD. But in the real platform, when MMC > works at 4-bit mode there will be a FIFO underrun error > (http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=3535). > While SD works at 4-bit mode is OK. We believe this is a hardware > issue of the SDIO host controller of BF54x. Odd. As there shouldn't be a difference, I'm inclined to believe that this is card dependent. So it could as well appear with some SD cards as well. How much have you tested this issue? That tracker entry isn't very verbose. Also, how can an underrun appear? The system should have flow control. And an underrun does not sound like a bus problem, rather that you have a card with different speed characteristics than the hardware/driver can handle. > > We intend to workaround in our own BF54x SDIO host controller driver, > but there is no place for us to determine MMC or SD. One choice is to > hack common code like this: _If_ it truly cannot handle 4-bit MMC, then Mike's patch is the way to go. But I'm not yet convinced that the problem is related to MMC vs SD. 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] split MMC_CAP_4_BIT_DATA
On Thu, 10 Jan 2008 17:22:55 +0800 "Bryan Wu" <[EMAIL PROTECTED]> wrote: > > At page 4-3 of ADSP-BF54x Blackfin(R) Processor Peripheral Hardware > Reference, there is a table which guide us the SDH controller does not > support 4-bit mode MMC card. Please found the table picture in the > attachment or get the document at: > http://www.analog.com/UploadedFiles/Associated_Docs/61460151169789ADSP_BF54x_Blackfin_Processor_Peripheral_Hardware_Reference.pdf > Ok, but this just means the controller wasn't designed with 4-bit MMC in mind. As several other "SD-only" controller have been tested with modern MMC cards without a problem, this is not sufficient to explain any problem. > > Thanks, actually we are not yet convinced by our hardware designer > why BF54x SDH does not support 4-bit MMC. > Please keep me informed on how it progresses. I'd like an at least plausible explanation, preferably also some empirical data, before I'm ready to accept Mike's patch. 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: Correct types for mod_devicetable.h (was: Re: m68k build failure)
On Sun, 2 Dec 2007 12:22:31 +0100 (CET) Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: > > I gave it a try: > - Remove existing alignment attributes from some device_id types > - Introduce kernel_* types with proper size and alignment for > cross-compilation (sample for m68k included) > - Introduce BITS_PER_KERNEL_LONG, to make it clearer it applies to the > target > > Apart from a cross-compile session for m68k, it's untested. > This still requires a bit of maintenance to set up a kerneltypes.h for every arch. It also means we have to be very careful that gcc's internal alignment settings matched the ones in our header. Rgds Pierre signature.asc Description: PGP signature
Re: Correct types for mod_devicetable.h (was: Re: m68k build failure)
On Sat, 8 Dec 2007 22:58:11 +0100 Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Mon, Dec 03, 2007 at 09:02:19PM +1100, Rusty Russell wrote: > > So, just insert two bits of padding in sdio_device_id and insert a comment > > saying "/* Explicit padding: works even if we're cross-compiling */". > > We had one such problem in 2.6.23 and now we had a similar one in 2.6.24. > > Getting the alignment issues automatically right would really be an > improvement... > Agreed. I won't veto a quick and dirty fix, but I would prefer if this could be solved properly. Rgds Pierre signature.asc Description: PGP signature
Re: [PATCH] mmc: remove unused 'mode' from the mmc_host structure
On Thu, 06 Dec 2007 23:12:46 -0500 (EST) Nicolas Pitre <[EMAIL PROTECTED]> wrote: > This field and corresponding defines are simply never used anywhere > in the code. But its mere presence is enough to confuse some host > driver authors who attempt to rely on it. Let's eliminate the > possibility for confusion and remove it entirely. > > Signed-off-by: Nicolas Pitre <[EMAIL PROTECTED]> > --- Oopsie. Some old stuff since before the restructuring. > > yes, it's the second host driver I'm reviewing with this issue... > Seems to be a bit of Windows mentality that spills over. Maybe you should give them a quick tutorial in that in Linux we fix stuff at the source. ;) Thanks for the patch. I've queued it up. Rgds Pierre signature.asc Description: PGP signature
Re: Correct types for mod_devicetable.h (was: Re: m68k build failure)
On Mon, 10 Dec 2007 19:11:12 +0100 Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Sun, Dec 09, 2007 at 06:08:18PM +0100, Pierre Ossman wrote: > > > > This still requires a bit of maintenance to set up a kerneltypes.h for > > every arch. > > Better doing this work once than fixing similar issues again and again. > Agreed. But it raises the bar quite a bit to get this ready for upstream. > > It also means we have to be very careful that gcc's internal alignment > > settings matched the ones in our header. > > There's nothing "gcc internal" about struct alignment - remember that > any change in struct alignment would change our userspace ABI. > Oh? I would have guessed that everything going to and from userspace would be packed. Should probably consider myself lucky I have do deal with few such interactions. :) Rgds Pierre signature.asc Description: PGP signature
[GIT PULL] MMC updates
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus to receive the following updates: drivers/mmc/host/sdhci.c | 63 ++--- drivers/mmc/host/sdhci.h |3 +- include/linux/mmc/host.h |4 --- include/linux/pci_ids.h |1 + 4 files changed, 61 insertions(+), 10 deletions(-) Nicolas Pitre (1): mmc: remove unused 'mode' from the mmc_host structure Pierre Ossman (4): sdhci: describe quirks sdhci: don't warn about sdhci 2.0 controllers sdhci: use PIO when DMA can't satisfy the request sdhci: support JMicron JMB38x chips -- -- 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: PNP: do not stop/start devices in suspend/resume path
On Thu, 6 Dec 2007 16:25:57 -0700 Bjorn Helgaas <[EMAIL PROTECTED]> wrote: > PNP: do not stop/start devices in suspend/resume path > > Do not disable PNP devices in the suspend path. We still call > the driver's suspend method, which should prevent further use of > the device, and the protocol suspend method, which may put the > device in a low-power state. > > I'm told that Windows puts devices in a low-power state (Linux > does this in the protocol suspend method), but does not use _DIS > in the suspend path. Other relevant references: > > - In the ACPI 3.0b spec, I can't find any mention of _DIS in > connection with sleep. And Device Object Notifications, > Section 5.6.3, Table 5-43, says we should get a bus check > after awakening if hardware was removed while we slept. > > - This: http://msdn2.microsoft.com/en-us/library/ms810079.aspx > makes a similar point about how the OS re-enumerates devices > as a result of a power state change (3rd last paragraph of > text). > > - This: http://msdn2.microsoft.com/en-us/library/aa489874.aspx > suggests that Windows only stops a device to rebalance hardware > resources. > > Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]> > Tested-by: Pierre Ossman <[EMAIL PROTECTED]> No noticeable issues with suspend or hibernate using this patch. Rgds Pierre signature.asc Description: PGP signature
Re: [PATCH][MMC] Fix wrong EXT_CSD_REV handling
On Thu, 13 Dec 2007 16:13:11 +0900 Kyungmin Park <[EMAIL PROTECTED]> wrote: > It already checked the ext_csd_struct is less than 2, > so it doesn't need to check it. > Current code only accepts the revision 1.2. > > Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]> It wasn't wrong the last time you brought this up, and it still isn't wrong. Those bits aren't defined until version 1.2 of the EXT_CSD register, hence we do not trust them. If you have some broken card that you feel you must have support for, then start working on some quirks system. 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][MMC] Fix wrong EXT_CSD_REV handling
On Thu, 13 Dec 2007 17:08:16 +0900 "Kyungmin Park" <[EMAIL PROTECTED]> wrote: > > In my MMC Spec. (v4.2), there's no problem to read it even though it's > revision 1.1 > Well, the spec says that those reserved fields "should be zero". Unfortunately, people seem to have read this in the IETF sense and not as "the fields MUST be zero". I.e. I've seen cards where reserved fields contain junk. > Anyway how do it handle this one? Do you have any idea? > The EXT_CSD is read after the CID, so add some table that maps certain workarounds to specific cards. Then add some bit saying "is really EXT_CSD 1.2" and check for that bit when parsing the EXT_CSD. 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] mmc: Disabler for Ricoh MMC controller
On Tue, 02 Oct 2007 17:14:34 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > Hrm... allright, tho having this "disabler" driver is butt ugly > too ... especially since it needs to whack registers in another > function, that's really quirkland :-) > Well, that issue would remain even if we put it into sdhci.c. Perhaps something can be done when sdhci is split into multiple parts, but not right now. Rgds Pierre signature.asc Description: PGP signature
Re: What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...
On Wed, 03 Oct 2007 19:41:16 -0400 Trond Myklebust <[EMAIL PROTECTED]> wrote: > > We also have the 64-bit inode support from RedHat/Peter Staubach. > As has been pointed[1] out[2], this will cause regressions for non-LFS applications (of which there are still lots and lots). This change should be in feature-removal (the "feature" being removed is legacy support for non-LFS applications using NFS servers that make full use of the protocol) and preferably accompanied with appropriate user space changes (e.g. compatibility option in glibc). [1] https://bugzilla.redhat.com/show_bug.cgi?id=241348 [2] http://marc.info/?l=linux-nfs&m=118701088726477&w=2 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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Wed, 3 Oct 2007 23:16:59 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 03 Oct 2007 23:11:02 -0700 Don Mullis <[EMAIL PROTECTED]> wrote: > > > OOPS followed by a 3 minute timeout, then completion of boot. > > Not seen if card (Kingston microSD adapter) is ejected; not seen in > > 2.6.23-rc8. Running on a Dell XPS M1330 laptop. > > Impossible! My code is bug free! > > [ 13.709831] EIP is at blk_rq_map_sg+0xc0/0x160 > > [ 13.711857] Call Trace: > > [ 13.711971] [] mmc_queue_map_sg+0x28/0xc0 [mmc_block] > > [ 13.712085] [] mmc_blk_issue_rq+0x199/0x780 [mmc_block] > > [ 13.712193] [] mmc_queue_thread+0x78/0xe0 [mmc_block] Seems to be in the handling of the bounce buffer. I don't see how any of the parameters to blk_rq_map_sg() could be incorrect though, so I suspect the problem is not in the mmc layer. Don, is MMC_BLOCK_BOUNCE enabled? Could you try toggling it and see if things change? > > This could be due to git-block changes (or a lack of them ;)) > There are no pending patches, or recent changes that mess about in any real way in there. Don, when did this work last? Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 09:25:15 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > > It looks like missing init of the sg list in mmc, does this work? > Huh? Isn't the block layer supposed to fill in the entire thing? (i.e. current contents shouldn't matter) Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 10:06:32 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > On Thu, Oct 04 2007, Pierre Ossman wrote: > > > > Huh? Isn't the block layer supposed to fill in the entire thing? > > (i.e. current contents shouldn't matter) > > Yeah, but sg chaining requires that ->page be filled in properly or it > could confuse it. I think I'll add some debugging to catch that. > I assume sg_init_one() still can work on an uninitialized sg entry? Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 12:38:05 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > On Thu, Oct 04 2007, Pierre Ossman wrote: > > > > Is that a yes or a no? You said that the ->page field was involved > > in > > It's a conditional yes, re-read it :-) > I didn't get the memo about what chained sg entries entail. > > list chaining, so does or doesn't it have to be initialized before a > > call to sg_init_one()? > > That's not the problem. It has to be initialized before calling > blk_rq_map_sg(). sg_init_one() will zero the entire sg entry, and that > breaks if that particular sg entry is part of a larger sg table AND > that sg entry happens to be the chain element. > Ok, then it shouldn't affect my world at least. Rgds Pierre PS. Did someone forget to do a review of all blk_rq_map_sg() callers before committing the chained list stuff? ;) signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 11:30:14 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > On Thu, Oct 04 2007, Pierre Ossman wrote: > > > > I assume sg_init_one() still can work on an uninitialized sg entry? > > Yes, but only if that sg entry is not part of a chained list. > Is that a yes or a no? You said that the ->page field was involved in list chaining, so does or doesn't it have to be initialized before a call to sg_init_one()? Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 04 Oct 2007 09:19:40 -0700 Don Mullis <[EMAIL PROTECTED]> wrote: > This patch fixes the boot. > Fantastic. Then will try to get this upstream then. > > > > It looks like missing init of the sg list in mmc, does this work? > > Jens, is this zeroing needed for each invocation, or really just once to get the list in a known state? Also, is chaining already upstream so Linus should have this for 2.6.23? Rgds Pierre signature.asc Description: PGP signature
Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...
On Thu, 04 Oct 2007 10:00:50 -0400 Trond Myklebust <[EMAIL PROTECTED]> wrote: > On Thu, 2007-10-04 at 08:52 +0200, Pierre Ossman wrote: > > On Wed, 03 Oct 2007 19:41:16 -0400 > > Trond Myklebust <[EMAIL PROTECTED]> wrote: > > > > > > > > We also have the 64-bit inode support from RedHat/Peter Staubach. > > > > > > > As has been pointed[1] out[2], this will cause regressions for > > non-LFS applications (of which there are still lots and lots). This > > change should be in feature-removal (the "feature" being removed is > > legacy support for non-LFS applications using NFS servers that make > > full use of the protocol) and preferably accompanied with > > appropriate user space changes (e.g. compatibility option in glibc). > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=241348 > > [2] http://marc.info/?l=linux-nfs&m=118701088726477&w=2 > > > > Rgds > > How about a boot/module parameter to turn it on or off? > That would be perfect. It can even be in non-legacy mode by default, just as long as you can go back to the old behaviour when/if you run into a non-LFS application. > I don't see any point in having a sysctl for something like this: > either you have legacy applications or you don't. It is not something > that you switch off as you go off to lunch. > A compile parameter, OTOH, would be too restrictive since it would > force distros to choose just one behaviour (which would mean they > would have to choose the most conservative). > Agreed. 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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 18:42:25 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > > diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c > index b0abc7d..a5d0354 100644 > --- a/drivers/mmc/card/queue.c > +++ b/drivers/mmc/card/queue.c Acked-by: Pierre Ossman <[EMAIL PROTECTED]> (Provided it works ;)) I have no patches touching queue.c in my tree, so there should be no problems with merge conflicts. Rgds Pierre signature.asc Description: PGP signature
Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...
On Thu, 04 Oct 2007 15:41:57 -0400 Peter Staubach <[EMAIL PROTECTED]> wrote: > > I would agree. The 64 bit fileids will only become visible when > the server is exporting file systems which contain fileids which > are bigger than 32 bits and then only when the application > encounters these files. > Or, as has been pointed out, when the server is not the Linux in-kernel NFS server. > Also, these 32-bit legacy applications are going to have a > problem if they are ever run on a system which contains local > file systems which expose the large fileids. > Agreed. And I'd probably like a way around that as well. But local files have never worked, NFS has. So removing it from NFS (where it is more likely to occur IMO) would be a regression. > It would be better to identify these applications and get them > fixed. The world is evolving and it is time for them to do so. > Print a warning or something so that they can be found. Don't go breaking systems left and right. People have better things to do than to fix the build systems for ever program they use. 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: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...
On Fri, 05 Oct 2007 13:36:19 -0400 Trond Myklebust <[EMAIL PROTECTED]> wrote: > On Fri, 2007-10-05 at 08:25 +0200, Pierre Ossman wrote: > > > Print a warning or something so that they can be found. Don't go > > breaking systems left and right. People have better things to do > > than to fix the build systems for ever program they use. > > The kernel knows bugger all about what glibc function your program is > calling. The problem here is precisely that newer versions of glibc > will transform legacy 32-bit stat() calls into 64-bit stat64() calls, > then will complain when the result overflows. > Right, I didn't suggest that this had to be done in the kernel. My point was that first you mark something as deprecated, make a lot of noise when someone uses it so that problems can be identified, and some time later you remove it. You don't just remove it and let production systems deal with the fallout. 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: idio{,ma}tic typos (was Re: + fix-vm_can_nonlinear-check-in-sys_remap_file_pages.patch added to -mm tree)
On Wed, 10 Oct 2007 14:45:40 +0400
Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> ["if (!x & y)" patch from [EMAIL PROTECTED]
> ["if (!x & y)" patch from [EMAIL PROTECTED]
> ["if (!x & y)" patches from [EMAIL PROTECTED]
>
> While we're at it, below is somewhat ugly sparse patch for detecting
> "&& 0x" typos.
>
The maintainer for tifm is Alex Dubov, so cc:ing him.
> drivers/mmc/host/tifm_sd.c:183:9: warning: dubious && 0x
>
> if ((r_data->flags & MMC_DATA_WRITE)
> && DATA_CARRY)
> writel(host->bounce_buf_data[0],
> host->dev->addr
> + SOCK_MMCSD_DATA);
>
> given that DATA_CARRY is always used together with
> ->cmd_flags, this place is asking for obvious fixlet:
>
>
> [PATCH] tifm_sd.c: fix DATA_CARRY check
>
> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
> ---
>
> drivers/mmc/host/tifm_sd.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/mmc/host/tifm_sd.c
> +++ b/drivers/mmc/host/tifm_sd.c
> @@ -180,7 +180,7 @@ static void tifm_sd_transfer_data(struct tifm_sd
> *host) host->sg_pos++;
> if (host->sg_pos == host->sg_len) {
> if ((r_data->flags & MMC_DATA_WRITE)
> - && DATA_CARRY)
> + && (host->cmd_flags &
> DATA_CARRY)) writel(host->bounce_buf_data[0],
> host->dev->addr
> + SOCK_MMCSD_DATA);
>
>
>
Rgds
Pierre
signature.asc
Description: PGP signature
[GIT PULL] MMC updates
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus Lot's of changes in here. Mostly it is SDIO and SPI support, although there are things like removal of MMC layer specific error codes. diffstat: MAINTAINERS |8 +- arch/arm/mach-imx/mx1ads.c |2 +- drivers/mmc/card/Kconfig|7 + drivers/mmc/card/Makefile |2 + drivers/mmc/card/block.c| 30 +- drivers/mmc/card/sdio_uart.c| 1158 drivers/mmc/core/Makefile |4 +- drivers/mmc/core/bus.c | 67 ++- drivers/mmc/core/core.c | 167 -- drivers/mmc/core/core.h |2 + drivers/mmc/core/host.c |8 + drivers/mmc/core/mmc.c | 134 +++-- drivers/mmc/core/mmc_ops.c | 200 +-- drivers/mmc/core/mmc_ops.h |3 + drivers/mmc/core/sd.c | 126 +++-- drivers/mmc/core/sd_ops.c | 107 ++- drivers/mmc/core/sdio.c | 395 +++ drivers/mmc/core/sdio_bus.c | 270 drivers/mmc/core/sdio_bus.h | 22 + drivers/mmc/core/sdio_cis.c | 346 ++ drivers/mmc/core/sdio_cis.h | 23 + drivers/mmc/core/sdio_io.c | 548 +++ drivers/mmc/core/sdio_irq.c | 267 drivers/mmc/core/sdio_ops.c | 176 + drivers/mmc/core/sdio_ops.h | 22 + drivers/mmc/host/Kconfig| 30 + drivers/mmc/host/Makefile |2 + drivers/mmc/host/at91_mci.c | 25 +- drivers/mmc/host/au1xmmc.c | 58 +- drivers/mmc/host/imxmmc.c | 32 +- drivers/mmc/host/mmc_spi.c | 1408 +++ drivers/mmc/host/mmci.c | 20 +- drivers/mmc/host/omap.c | 12 +- drivers/mmc/host/pxamci.c | 71 ++- drivers/mmc/host/pxamci.h |2 + drivers/mmc/host/ricoh_mmc.c| 151 + drivers/mmc/host/sdhci.c| 127 +++-- drivers/mmc/host/sdhci.h|2 +- drivers/mmc/host/tifm_sd.c | 31 +- drivers/mmc/host/wbsd.c | 43 +- include/asm-arm/arch-imx/mmc.h |5 +- include/linux/mmc/card.h| 32 + include/linux/mmc/core.h| 63 ++- include/linux/mmc/host.h| 39 +- include/linux/mmc/mmc.h | 39 +- include/linux/mmc/sdio.h| 159 + include/linux/mmc/sdio_func.h | 153 + include/linux/mmc/sdio_ids.h| 23 + include/linux/mod_devicetable.h | 11 + include/linux/pci_ids.h |2 + include/linux/spi/mmc_spi.h | 33 + scripts/mod/file2alias.c| 20 + 52 files changed, 6257 insertions(+), 430 deletions(-) Adrian Bunk (1): make struct sdio_dev_attrs[] static Bridge Wu (3): mmc: pxamci: better pending IRQ determination mmc: pxamci: set proper buswidth capabilities according to PXA flavor mmc: pxamci: add SDIO card interrupt reporting capability David Brownell (4): MMC headers learn about SPI MMC/SD card driver learns SPI MMC core learns about SPI mmc_spi host driver David Vrabel (4): sdio: add SDIO_FBR_BASE(f) macro sdio: set the functions' block size sdio: extend sdio_readsb() and friends to handle any length of buffer sdio: add sdio_f0_readb() and sdio_f0_writeb() Feng Tang (2): sdhci: remove DMA capability check from controller's PCI Class reg sdhci: add SDHCI_QUIRK_BROKEN_DMA quirk Marc Pignat (1): mmc: at91_mci: disable handling of blocks with size not multiple of 4 bytes Mariusz Kozlowski (1): sdio: kmalloc + memset conversion to kzalloc Nicolas Pitre (16): sdio: initial CIS parsing code sdio: link unknown CIS tuples to the sdio_func structure mmc: initialize mmc subsystem with subsys_initcall() sdio: defines for some standard interface types sdio: allow for mmc_claim_host to be aborted sdio: core support for SDIO function interrupt sdio: UART/GPS driver sdio: add /proc interface to sdio_uart driver sdio: add interface for host side SDIO interrupt reporting sdio: add default c_ispeed/c_ospeed values to sdio_uart driver sdio: fix recursion issues between sdio-uart driver and tty layer mmc: pxamci: set proper block capabilities according to PXA flavor sdhci: fix a typo sdio: fix IRQ diagnostic message sdio: make the IRQ thread more resilient in the presence of bad states pxamci: support arbitrary block size Pavel Pisa (1): arm: i.MX/MX1 SDHC implements SD cards read-only switch read-back Philip Langdale (1): mmc: Disabler for Ricoh MMC controller Pierre Ossman (32): mmc: remove custom error codes mmc: improve error code feedback mmc: read ext_csd version number mmc: mmc_set_data_timeout() parameter write is redundant mmc: remove BYTEBLOCK capability mmc: remove confusing flag mmc: add missing printk levels m
Re: [GIT PULL] MMC updates
On Thu, 11 Oct 2007 22:30:41 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > There seems to be some breakage here: > > drivers/mmc/core/host.c: In function ‘mmc_remove_host’: > drivers/mmc/core/host.c:146: error: implicit declaration of > function ‘led_trigger_unregister’ drivers/mmc/core/host.c:146: error: > ‘struct mmc_host’ has no member named ‘led’ > > this was after doing a few "make randconfig" runs, a habit I'm trying > to encourage (and do myself occasionally too). > How embarrassing. I'll have a look at it and reping you when I've solved it. 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: relation between mmc_request, mmc_data and mmc_command
On Sun, 23 Dec 2007 23:25:26 -0800 "raki john" <[EMAIL PROTECTED]> wrote: > > Does mmc_requeest->stop is equal to mmc_request->data->stop ? > > Does mmc_request is equal to mmc_request->data->mrq ? > > Does mmc_request->data is equal to mmc_request->cmd->data ? > > Does mmc_request is equal to mmc_request->cmd->mrq ? > Yes on all accounts. I don't know the reason for this extreme redundancy. It was there long before I got involved. > > I think Stop command which is part of mmc_request is used for sending stop > command after Multi Block write. is this correct. If stop command fails(CRC > fail, timeout), does this mean card write failed. > It is correct that it is used for multi block writes. But also other open ended transfers. If the stop command fails, then the card will be in an unknown state. The write should have been completed though. Rgds Pierre signature.asc Description: PGP signature
Re: Order of Loading mmc driver modules.
On Wed, 26 Dec 2007 10:40:22 -0800 "raki john" <[EMAIL PROTECTED]> wrote: > Hi All, > > I am working with pxamci driver(2.6.22.1). I have made , core and host > as separate modules. > > what is the correct order of loading the modules > > i am doing in this order first core (mmc_core.ko), then card(mmc_block.ko) > after that host driver ( pxamci.ko). Is this correct. > If you're using just insmod, then yes, this is a valid order. The only thing that is crucial is that mmc_core is loaded before any of the other. If you use modprobe that will happen automatically. > I do not know much about Linux device model. > There's lots of info on the web and in the Documentation/ directory of the kernel source if you want to indulge yourself. > i saw that pxamci.ko driver registers it self as platform_driver. When > does its probe function is called. Is it called immediately after > platform_driver_register(&pxamci_driver) is called. > For pxamci, yes. More specifically, the probe function is called when there is both a driver (created by platform_driver_register()) and a device (platform_device_register()) available. But since the device is added very early in the pxamci case, the magic will happen when the driver registers. > also in card driver (mmc_block.ko) in block.c file i saw a probe > function(mmc_blk_probe). How does it is invoked . > When the corresponding device is registered. In this case it is whenever a card is detected and initialized. Rgds Pierre signature.asc Description: PGP signature
[GIT PULL] MMC update
Linus, please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus
to receive the following updates:
drivers/mmc/card/sdio_uart.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Andre Haupt (1):
sdio_uart: fix sign of paramter status in sdio_uart_receive_chars()
diff --git a/drivers/mmc/card/sdio_uart.c b/drivers/mmc/card/sdio_uart.c
index d552de6..eeea84c 100644
--- a/drivers/mmc/card/sdio_uart.c
+++ b/drivers/mmc/card/sdio_uart.c
@@ -386,7 +386,7 @@ static void sdio_uart_stop_rx(struct sdio_uart_port *port)
sdio_out(port, UART_IER, port->ier);
}
-static void sdio_uart_receive_chars(struct sdio_uart_port *port, int *status)
+static void sdio_uart_receive_chars(struct sdio_uart_port *port, unsigned int
*status)
{
struct tty_struct *tty = port->tty;
unsigned int ch, flag;
--
-- 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/
Fedora's latest gcc produces unbootable kernels
The latest GCC in Fedora rawhide contains some serious bug (or provokes a latent one in the kernel) that makes every kernel built unbootable. It just locks up halfway through the init. Kernels that previously worked fine all now experience the same symptom. Even RH's own kernels exhibit this. The kernel built Nov 24th works, Nov 26th doesn't. gcc was updated 26th, 14 hours earlier. The last message printed is: isapnp: Scanning for PnP cards... Comparing with the working kernel, the next steps are: isapnp: Scanning for PnP cards... Switched to high resolution mode on CPU 0 isapnp: No Plug & Play device found Any ideas on how I can work around this? I'm rather unproductive when I can't build working kernels.. :/ 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: Fedora's latest gcc produces unbootable kernels
On Sat, 1 Dec 2007 15:42:23 +0100 Pierre Ossman <[EMAIL PROTECTED]> wrote: > The latest GCC in Fedora rawhide contains some serious bug (or provokes a > latent one in the kernel) that makes every kernel built unbootable. It just > locks up halfway through the init. Kernels that previously worked fine all > now experience the same symptom. Even RH's own kernels exhibit this. The > kernel built Nov 24th works, Nov 26th doesn't. gcc was updated 26th, 14 hours > earlier. > Digging a bit further, it is indeed the high-res stuff (the first missing message) that hangs. If I hard code the kernel to just be non-high-res capable, it boots, but time keeping is horribly broken. Anyway, hopefully this means I'll soon have the object file that gets miscompiled. Jakub also pointed me to an older gcc RPM so that I can produce an object file with that as well and see what differs. 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: Fedora's latest gcc produces unbootable kernels
On Sat, 01 Dec 2007 13:37:44 -0500 Bill Davidsen <[EMAIL PROTECTED]> wrote: > If you are referring to the "compat" RPMs, be aware that they use the > current headers, which is a good or bad thing depending on what you want > to do. If you want to build old software, you get to keep a down-rev > virtual machine to do it right :-( > Nah. The previous gcc package is the one shipped with Fedora 8. So I could just grab that one (plus cpp and libgomp) and downgrade. 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/
