Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown
Andrew Morton wrote: (Please do reply-to-all) Jindrich Makovicka <[EMAIL PROTECTED]> wrote: Pavel Machek wrote: Hi! In `subj` kernel, machine no longer powers down at the end of swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk. For me, power down stopped working since the introduction of softlockup detection. After disabling CONFIG_DETECT_SOFTLOCKUP, powerdown works fine. Could you send the output which CONFIG_DETECT_SOFTLOCKUP generates? I had one CONFIG_DETECT_SOFTLOCKUP failure with suspend, on SMP. The machine was stuck somewhere under mce_work_fn(). Perhaps in the smp_call_function(). It only happened the once. Strange enough, softlockup produces no additional output. Kernel just prints "acpi_power_off called" and freezes. Without softlockup detection compiled in it turns off normally. First I was under impression that this is caused by acpi_power_off-bug-fix.patch mentioned above, but unfortunately removing it didn't actually solve the problem. Later I found I missed that softlockup detection sneaked in turned on by default, and disabling it made power off work again. Power down via APM produced some softlockup output, but I am not sure if APM actually worked on my machine before - I just tried APM if it works when ACPI doesn't, and didn't bother taking a snapshot. I can recompile an APM kernel with softlockup enabled and disabled and test it, if it could help. -- Jindrich Makovicka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects
On Wed, Mar 02, 2005 at 01:18:17PM -0800, Andrew Morton wrote: > Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > > > Thing is, CRYPTO_AES on only selectable on x86. > > > > You're thinking about CRYPTO_AES_586. But looking at crypto/Kconfig, > > the dependencies are a bit weird: > > > > config CRYPTO_AES > > tristate "AES cipher algorithms" > > depends on CRYPTO && !(X86 && !X86_64) > > config CRYPTO_AES_586 > > tristate "AES cipher algorithms (i586)" > > depends on CRYPTO && (X86 && !X86_64) > > That's pretty broken, isn't it? > > Would be better to just do: > > config CRYPTO_AES > select CRYPTO_AES_586 if (X86 && !X86_64) > select CRYPTO_AES_OTHER if !(X86 && !X86_64) > > and hide CRYPTO_AES_586 and CRYPTO_AES_OTHER from the outside world. http://www.ussg.iu.edu/hypermail/linux/kernel/0502.3/0518.html http://www.ussg.iu.edu/hypermail/linux/kernel/0502.3/0523.html cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects
On Wed, Mar 02, 2005 at 05:41:50PM -0500, Jeff Garzik wrote: > Andrew Morton wrote: > >Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > >>>Thing is, CRYPTO_AES on only selectable on x86. > >> > >>You're thinking about CRYPTO_AES_586. But looking at crypto/Kconfig, > >>the dependencies are a bit weird: > >> > >>config CRYPTO_AES > >> tristate "AES cipher algorithms" > >> depends on CRYPTO && !(X86 && !X86_64) > >>config CRYPTO_AES_586 > >> tristate "AES cipher algorithms (i586)" > >> depends on CRYPTO && (X86 && !X86_64) > > > > > >That's pretty broken, isn't it? > > > >Would be better to just do: > > > >config CRYPTO_AES > > select CRYPTO_AES_586 if (X86 && !X86_64) > > select CRYPTO_AES_OTHER if !(X86 && !X86_64) > > > >and hide CRYPTO_AES_586 and CRYPTO_AES_OTHER from the outside world. > > Not really that easy. For x86 we have > > aes > aes-586 > aes-via Where is aes-via? > And my own personal custom-kernel preference is to use the C version of > the code on my x86 and x86-64 boxes. That's already not possible today. > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown
(Please do reply-to-all) Jindrich Makovicka <[EMAIL PROTECTED]> wrote: > > Pavel Machek wrote: > > Hi! > > > > In `subj` kernel, machine no longer powers down at the end of > > swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk. > > For me, power down stopped working since the introduction of softlockup > detection. After disabling CONFIG_DETECT_SOFTLOCKUP, powerdown works fine. Could you send the output which CONFIG_DETECT_SOFTLOCKUP generates? I had one CONFIG_DETECT_SOFTLOCKUP failure with suspend, on SMP. The machine was stuck somewhere under mce_work_fn(). Perhaps in the smp_call_function(). It only happened the once. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown
Pavel Machek wrote: Hi! In `subj` kernel, machine no longer powers down at the end of swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk. For me, power down stopped working since the introduction of softlockup detection. After disabling CONFIG_DETECT_SOFTLOCKUP, powerdown works fine. -- Jindrich Makovicka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects
Adrian Bunk wrote: On Wed, Mar 02, 2005 at 05:41:50PM -0500, Jeff Garzik wrote: Andrew Morton wrote: Jeff Garzik <[EMAIL PROTECTED]> wrote: Thing is, CRYPTO_AES on only selectable on x86. You're thinking about CRYPTO_AES_586. But looking at crypto/Kconfig, the dependencies are a bit weird: config CRYPTO_AES tristate "AES cipher algorithms" depends on CRYPTO && !(X86 && !X86_64) config CRYPTO_AES_586 tristate "AES cipher algorithms (i586)" depends on CRYPTO && (X86 && !X86_64) That's pretty broken, isn't it? Would be better to just do: config CRYPTO_AES select CRYPTO_AES_586 if (X86 && !X86_64) select CRYPTO_AES_OTHER if !(X86 && !X86_64) and hide CRYPTO_AES_586 and CRYPTO_AES_OTHER from the outside world. Not really that easy. For x86 we have aes aes-586 aes-via Where is aes-via? drivers/crypto And my own personal custom-kernel preference is to use the C version of the code on my x86 and x86-64 boxes. That's already not possible today. It should be. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects
Andrew Morton wrote: Jeff Garzik <[EMAIL PROTECTED]> wrote: Thing is, CRYPTO_AES on only selectable on x86. You're thinking about CRYPTO_AES_586. But looking at crypto/Kconfig, the dependencies are a bit weird: config CRYPTO_AES tristate "AES cipher algorithms" depends on CRYPTO && !(X86 && !X86_64) config CRYPTO_AES_586 tristate "AES cipher algorithms (i586)" depends on CRYPTO && (X86 && !X86_64) That's pretty broken, isn't it? Would be better to just do: config CRYPTO_AES select CRYPTO_AES_586 if (X86 && !X86_64) select CRYPTO_AES_OTHER if !(X86 && !X86_64) and hide CRYPTO_AES_586 and CRYPTO_AES_OTHER from the outside world. Not really that easy. For x86 we have aes aes-586 aes-via And my own personal custom-kernel preference is to use the C version of the code on my x86 and x86-64 boxes. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects
Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > Would be better to just do: > > > > config CRYPTO_AES > > select CRYPTO_AES_586 if (X86 && !X86_64) > > select CRYPTO_AES_OTHER if !(X86 && !X86_64) > > > > and hide CRYPTO_AES_586 and CRYPTO_AES_OTHER from the outside world. > > > http://www.ussg.iu.edu/hypermail/linux/kernel/0502.3/0518.html Please resubmit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects
On Wed, Mar 02, 2005 at 02:12:04PM -0500, Jeff Garzik wrote: > Adrian Bunk wrote: > >On Wed, Mar 02, 2005 at 01:43:04AM -0500, Jeff Garzik wrote: > > > >>Adrian Bunk wrote: > >> > >>>+ select CRYPTO > >>> select CRYPTO_AES > >>> ---help--- > >>> Include software based cipher suites in support of IEEE 802.11i > >>> (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled > >>> networks. > >>>@@ -54,10 +55,11 @@ > >>> "ieee80211_crypt_ccmp". > >>> > >>>config IEEE80211_CRYPT_TKIP > >>> tristate "IEEE 802.11i TKIP encryption" > >>> depends on IEEE80211 > >>>+ select CRYPTO > >>> select CRYPTO_MICHAEL_MIC > >> > >> > >>'select CRYPTO_AES' should 'select CRYPTO' automatically, I would hope. > > > > > >This would result in a recursive dependency. > > No, it wouldn't. CRYPTO_AES depends on CRYPTO, which depends on nothing. Exactly. And if CRYPTO_AES would select CRYPTO, you'd have a recursive dependency. The only possible thing would be to change all dependencies on CRYPTO to selects. This wouldn't be unlogical since the whole crypto subsystem is only a helper for other subsystems. James, any opinions on this issue? > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects
Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > Thing is, CRYPTO_AES on only selectable on x86. > > You're thinking about CRYPTO_AES_586. But looking at crypto/Kconfig, > the dependencies are a bit weird: > > config CRYPTO_AES > tristate "AES cipher algorithms" > depends on CRYPTO && !(X86 && !X86_64) > config CRYPTO_AES_586 > tristate "AES cipher algorithms (i586)" > depends on CRYPTO && (X86 && !X86_64) That's pretty broken, isn't it? Would be better to just do: config CRYPTO_AES select CRYPTO_AES_586 if (X86 && !X86_64) select CRYPTO_AES_OTHER if !(X86 && !X86_64) and hide CRYPTO_AES_586 and CRYPTO_AES_OTHER from the outside world. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects
Andrew Morton wrote: Jeff Garzik <[EMAIL PROTECTED]> wrote: Adrian Bunk wrote: On Wed, Mar 02, 2005 at 01:43:04AM -0500, Jeff Garzik wrote: Adrian Bunk wrote: + select CRYPTO select CRYPTO_AES ---help--- Include software based cipher suites in support of IEEE 802.11i (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled networks. @@ -54,10 +55,11 @@ "ieee80211_crypt_ccmp". config IEEE80211_CRYPT_TKIP tristate "IEEE 802.11i TKIP encryption" depends on IEEE80211 + select CRYPTO select CRYPTO_MICHAEL_MIC 'select CRYPTO_AES' should 'select CRYPTO' automatically, I would hope. This would result in a recursive dependency. No, it wouldn't. CRYPTO_AES depends on CRYPTO, which depends on nothing. Thing is, CRYPTO_AES on only selectable on x86. You're thinking about CRYPTO_AES_586. But looking at crypto/Kconfig, the dependencies are a bit weird: config CRYPTO_AES tristate "AES cipher algorithms" depends on CRYPTO && !(X86 && !X86_64) config CRYPTO_AES_586 tristate "AES cipher algorithms (i586)" depends on CRYPTO && (X86 && !X86_64) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects
Jeff Garzik <[EMAIL PROTECTED]> wrote: > > Adrian Bunk wrote: > > On Wed, Mar 02, 2005 at 01:43:04AM -0500, Jeff Garzik wrote: > > > >>Adrian Bunk wrote: > >> > >>>+ select CRYPTO > >>> select CRYPTO_AES > >>> ---help--- > >>> Include software based cipher suites in support of IEEE 802.11i > >>> (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled > >>> networks. > >>>@@ -54,10 +55,11 @@ > >>> "ieee80211_crypt_ccmp". > >>> > >>>config IEEE80211_CRYPT_TKIP > >>> tristate "IEEE 802.11i TKIP encryption" > >>> depends on IEEE80211 > >>>+ select CRYPTO > >>> select CRYPTO_MICHAEL_MIC > >> > >> > >>'select CRYPTO_AES' should 'select CRYPTO' automatically, I would hope. > > > > > > This would result in a recursive dependency. > > No, it wouldn't. CRYPTO_AES depends on CRYPTO, which depends on nothing. > Thing is, CRYPTO_AES on only selectable on x86. So really, IEEE80211_CRYPT_CCMP should depend upon CRYPTO_AES rather than selecting it. But that confuses users. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects
Adrian Bunk wrote: On Wed, Mar 02, 2005 at 01:43:04AM -0500, Jeff Garzik wrote: Adrian Bunk wrote: + select CRYPTO select CRYPTO_AES ---help--- Include software based cipher suites in support of IEEE 802.11i (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled networks. @@ -54,10 +55,11 @@ "ieee80211_crypt_ccmp". config IEEE80211_CRYPT_TKIP tristate "IEEE 802.11i TKIP encryption" depends on IEEE80211 + select CRYPTO select CRYPTO_MICHAEL_MIC 'select CRYPTO_AES' should 'select CRYPTO' automatically, I would hope. This would result in a recursive dependency. No, it wouldn't. CRYPTO_AES depends on CRYPTO, which depends on nothing. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects
On Wed, Mar 02, 2005 at 01:43:04AM -0500, Jeff Garzik wrote: > Adrian Bunk wrote: > >+select CRYPTO > > select CRYPTO_AES > > ---help--- > > Include software based cipher suites in support of IEEE 802.11i > > (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled > > networks. > >@@ -54,10 +55,11 @@ > > "ieee80211_crypt_ccmp". > > > > config IEEE80211_CRYPT_TKIP > > tristate "IEEE 802.11i TKIP encryption" > > depends on IEEE80211 > >+select CRYPTO > > select CRYPTO_MICHAEL_MIC > > > 'select CRYPTO_AES' should 'select CRYPTO' automatically, I would hope. This would result in a recursive dependency. > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects
Adrian Bunk wrote: + select CRYPTO select CRYPTO_AES ---help--- Include software based cipher suites in support of IEEE 802.11i (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled networks. @@ -54,10 +55,11 @@ "ieee80211_crypt_ccmp". config IEEE80211_CRYPT_TKIP tristate "IEEE 802.11i TKIP encryption" depends on IEEE80211 + select CRYPTO select CRYPTO_MICHAEL_MIC 'select CRYPTO_AES' should 'select CRYPTO' automatically, I would hope. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown
Hi! > > > Relocating pagedir | > > > Reading image data (8157 pages): 100% 8157 done. > > > Stopping tasks: | > > > Freeing memory... done (0 pages freed) > > > Freezing CPUs (at 1)...Sleeping in: > > > [] dump_stack+0x19/0x20 > > > [] smp_pause+0x1f/0x54 > > > [] smp_call_function_interrupt+0x3b/0x60 > > > [] call_function_interrupt+0x1c/0x24 > > > [] cpu_idle+0x55/0x64 > > > [] start_secondary+0x71/0x78 > > > [<>] 0x0 > > > [] 0xcffa5fbc > > > ok > > > double fault, gdt at c1203260 [255 bytes] > > > NMI Watchdog detected LOCKUP on CPU1, eip c0133c96, registers: > > Note the double fault. Yes, I can see it, it scares me. SMP swsusp is not in good state because I do not have easy access to SMP or HT hardware. I guess I'll just have to get into suse at the night and steal some P4 ;-). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown
Pavel Machek <[EMAIL PROTECTED]> wrote: > > I can fix disk going yo-yo without switching pm_message_t to struct, > but will have to back parts of that later. Do you want patch? No thanks, I was just pointing it out. It sounds like you have it under control. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown
Pavel Machek <[EMAIL PROTECTED]> wrote: > > Hi! > > > Resume on SMP locks up. > > Does it work on UP kernel on same hardware? yup. > NMI watchdog is problem > for suspend, it takes long to do various phases. Can you disable it > for testing? Will try to remember to do that. > > Relocating pagedir | > > Reading image data (8157 pages): 100% 8157 done. > > Stopping tasks: | > > Freeing memory... done (0 pages freed) > > Freezing CPUs (at 1)...Sleeping in: > > [] dump_stack+0x19/0x20 > > [] smp_pause+0x1f/0x54 > > [] smp_call_function_interrupt+0x3b/0x60 > > [] call_function_interrupt+0x1c/0x24 > > [] cpu_idle+0x55/0x64 > > [] start_secondary+0x71/0x78 > > [<>] 0x0 > > [] 0xcffa5fbc > > ok > > double fault, gdt at c1203260 [255 bytes] > > NMI Watchdog detected LOCKUP on CPU1, eip c0133c96, registers: Note the double fault. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown
Pavel Machek <[EMAIL PROTECTED]> writes: > > I threw it together to test a specific code path, and the fact it > > fails in software suspend is actually almost confirmation that I am on > > the right track. This actually fixed the case I was testing. > > > > In this case the failure is simply because system_state is > > not set to SYSTEM_POWER_OFF before > > kernel/power/disk.c:power_down() calls device_shutdown(). > > The appropriate reboot notifier is also not called.. > > Can you suggest patch to do it right? Or perhaps there should be > just_plain_power_machine_down() that does all neccessary > trickery? I would call it kernel_power_down() and that is what I am suggesting is the right fix. We have it open coded in kernel/sys.c:sys_reboot() in the switch case for: LINUX_REBOOT_CMD_POWER_OFF So after the code gets factored out from there all of the cases that call machine_power_off() and pm_power_off() directly need to be updated. There are similar cases for machine_restart() and machine_halt(). But the power off case seems to be the most acute. My biggest problem with this is I get into the recursive code cleanup problem. Where I fix one piece and a bug is exposed somewhere else. And that then requires investigation and fixing. Fixing the callers of machine_power_off() is about the fifth bug fix down the chain triggered by disabling UP interrupts in device_shutdown(), SMP interrupts have always been disabled. With the first bug fix was to create system devices in the device tree.. I haven't a clue where fixing this one will lead. Recursive code fixes are a hard thing to schedule :( Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown
Hi!
> btw, suspend is a bit messy. The disk spins down. Then up. Then down
> again. And:
Here's preview patch to make disk not do stupid yo-yo. Please do not
apply (it will probably not apply cleanly anyway).
I can fix disk going yo-yo without switching pm_message_t to struct,
but will have to back parts of that later. Do you want patch?
Pavel
--- clean/drivers/base/power/resume.c 2004-12-25 13:34:59.0 +0100
+++ linux/drivers/base/power/resume.c 2005-02-28 15:38:51.0 +0100
@@ -41,7 +41,7 @@
list_add_tail(entry, &dpm_active);
up(&dpm_list_sem);
- if (!dev->power.prev_state)
+ if (!dev->power.prev_state EVENT)
resume_device(dev);
down(&dpm_list_sem);
put_device(dev);
--- clean/drivers/base/power/runtime.c 2005-01-12 11:07:39.0 +0100
+++ linux/drivers/base/power/runtime.c 2005-02-28 15:42:10.0 +0100
@@ -13,10 +13,10 @@
static void runtime_resume(struct device * dev)
{
dev_dbg(dev, "resuming\n");
- if (!dev->power.power_state)
+ if (!dev->power.power_state EVENT)
return;
if (!resume_device(dev))
- dev->power.power_state = 0;
+ dev->power.power_state = PMSG_ON;
}
@@ -49,10 +49,10 @@
int error = 0;
down(&dpm_sem);
- if (dev->power.power_state == state)
+ if (dev->power.power_state EVENT == state EVENT)
goto Done;
- if (dev->power.power_state)
+ if (dev->power.power_state EVENT)
runtime_resume(dev);
if (!(error = suspend_device(dev, state)))
--- clean/drivers/base/power/shutdown.c 2004-08-15 19:14:55.0 +0200
+++ linux/drivers/base/power/shutdown.c 2005-01-12 10:57:23.0 +0100
@@ -29,7 +29,8 @@
dev->driver->shutdown(dev);
return 0;
}
- return dpm_runtime_suspend(dev, dev->detach_state);
+ /* FIXME */
+ return dpm_runtime_suspend(dev, PMSG_FREEZE);
}
--- clean/drivers/base/power/suspend.c 2005-01-12 11:07:39.0 +0100
+++ linux/drivers/base/power/suspend.c 2005-02-28 21:30:13.0 +0100
@@ -43,7 +43,7 @@
dev->power.prev_state = dev->power.power_state;
- if (dev->bus && dev->bus->suspend && !dev->power.power_state)
+ if (dev->bus && dev->bus->suspend && (!dev->power.power_state EVENT))
error = dev->bus->suspend(dev, state);
return error;
@@ -134,6 +134,8 @@
Done:
return error;
Error:
+ printk(KERN_ERR "Could not power down device %s: "
+ "error %d\n", kobject_name(&dev->kobj), error);
dpm_power_up();
goto Done;
}
--- clean/drivers/base/power/sysfs.c2004-08-15 19:14:55.0 +0200
+++ linux/drivers/base/power/sysfs.c2005-02-28 15:43:57.0 +0100
@@ -26,19 +26,20 @@
static ssize_t state_show(struct device * dev, char * buf)
{
- return sprintf(buf, "%u\n", dev->power.power_state);
+ return sprintf(buf, "%u\n", dev->power.power_state EVENT);
}
static ssize_t state_store(struct device * dev, const char * buf, size_t n)
{
- u32 state;
+ pm_message_t state;
char * rest;
int error = 0;
- state = simple_strtoul(buf, &rest, 10);
+ state EVENT = simple_strtoul(buf, &rest, 10);
+// state.flags = PFL_RUNTIME;
if (*rest)
return -EINVAL;
- if (state)
+ if (state EVENT)
error = dpm_runtime_suspend(dev, state);
else
dpm_runtime_resume(dev);
--- clean/drivers/ide/ide-disk.c2005-02-14 14:12:21.0 +0100
+++ linux/drivers/ide/ide-disk.c2005-02-14 22:34:43.0 +0100
@@ -872,7 +872,7 @@
{
switch (rq->pm->pm_step) {
case idedisk_pm_flush_cache:/* Suspend step 1 (flush cache)
complete */
- if (rq->pm->pm_state == 4)
+ if (rq->pm->pm_state == EVENT_FREEZE)
rq->pm->pm_step = ide_pm_state_completed;
else
rq->pm->pm_step = idedisk_pm_standby;
@@ -1155,8 +1155,7 @@
return;
}
- printk("Shutdown: %s\n", drive->name);
- dev->bus->suspend(dev, PM_SUSPEND_STANDBY);
+ dev->bus->suspend(dev, PMSG_SUSPEND);
}
/*
--- clean/drivers/ide/ide.c 2005-02-28 00:50:42.0 +0100
+++ linux/drivers/ide/ide.c 2005-02-28 15:48:21.0 +0100
@@ -1398,7 +1398,7 @@
rq.special = &args;
rq.pm = &rqpm;
rqpm.pm_step = ide_pm_state_start_suspend;
- rqpm.pm_state = state;
+ rqpm.pm_state = state EVENT;
return ide_do_drive_cmd(drive, &rq, ide_wait);
}
@@ -1417,7 +1417,7 @@
rq.special = &args;
rq.pm = &rqpm;
rqpm.pm_step = ide_pm_state_start_resume;
- rqpm.pm
Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown
Hi!
> btw, suspend is a bit messy. The disk spins down. Then up. Then down
> again. And:
Yes, this is going to be properly solved by switching pm_message_t to
struct (preview patch attached, EVENT will become .event, this is just
for me). I could do some hack to make disk not go up-down-up (and will
need to do it for suse9.3, anyway), but I do not think that would
belong to mainline.
> Powering off system
> Debug: sleeping function called from invalid context at
> include/linux/rwsem.h:66
> in_atomic():0, irqs_disabled():1
>
> [] dump_stack+0x19/0x20
> [] __might_sleep+0x91/0x9c
> [] device_shutdown+0x16/0x82
> [] power_down+0x47/0x74
> [] pm_suspend_disk+0x5a/0x74
> [] enter_state+0x2e/0x70
> [] software_suspend+0xa/0x10
> [] acpi_system_write_sleep+0x73/0x98
> [] vfs_write+0xaf/0x118
> [] sys_write+0x3c/0x68
> [] sysenter_past_esp+0x52/0x75
> Synchronizing SCSI cache for disk sda:
> Shutdown: hda
> acpi_power_off called
Hmm, device_shutdown is confused. Should it be called with interrupts
enabled or disabled? It uses rwsem, that suggests interrupts enabled,
but I do not think sysdev_shutdown with enabled interrupts is good
idea (and comment suggests it should be called with interrupts disabled).
Pavel
/**
* We handle system devices differently - we suspend and shut them
* down last and resume them first. That way, we don't do anything
stupid like
* shutting down the interrupt controller before any devices..
*
* Note that there are not different stages for power management calls
-
* they only get one called once when interrupts are disabled.
*/
extern int sysdev_shutdown(void);
/**
* device_shutdown - call ->shutdown() on each device to shutdown.
*/
void device_shutdown(void)
{
struct device * dev;
down_write(&devices_subsys.rwsem);
list_for_each_entry_reverse(dev, &devices_subsys.kset.list, kobj.entry)
{
pr_debug("shutting down %s: ", dev->bus_id);
if (dev->driver && dev->driver->shutdown) {
pr_debug("Ok\n");
dev->driver->shutdown(dev);
} else
pr_debug("Ignored.\n");
}
up_write(&devices_subsys.rwsem);
sysdev_shutdown();
}
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown
Hi! > > > In `subj` kernel, machine no longer powers down at the end of > > > swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk. > > > > Binary searching indicates that this is due to > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/broken-out/acpi_power_off-bug-fix.patch. > > > > > > I'll drop it. That patch is pretty ugly-looking anyway (ACPI code in > > drivers/base/power/?). > > > > Perhaps someone who is hitting the problem which that patch addresses could > > raise a bugzilla entry. > > > > Oh. It has one. http://bugme.osdl.org/show_bug.cgi?id=4041 > > > > Anyway. It needs more work. > > Agreed. > > I threw it together to test a specific code path, and the fact it > fails in software suspend is actually almost confirmation that I am on > the right track. This actually fixed the case I was testing. > > In this case the failure is simply because system_state is > not set to SYSTEM_POWER_OFF before > kernel/power/disk.c:power_down() calls device_shutdown(). > The appropriate reboot notifier is also not called.. Can you suggest patch to do it right? Or perhaps there should be just_plain_power_machine_down() that does all neccessary trickery? Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown
Hi! > > Yes, the patch is very ugly. If something like this needs to be done, > > then perhaps acpi should properly register into driver model and do > > the work there. This will also mean code will be called consistently. > > I totally agree. Do you have an example of how a non-device > can do this? > > In particular something that gets as close to shutting down > the system devices as possible. But gets called before that. > > Or perhaps acpi should simply be setup to be the first system device? I believe that's the prefered solution. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown
Pavel Machek <[EMAIL PROTECTED]> writes: > Yes, the patch is very ugly. If something like this needs to be done, > then perhaps acpi should properly register into driver model and do > the work there. This will also mean code will be called consistently. I totally agree. Do you have an example of how a non-device can do this? In particular something that gets as close to shutting down the system devices as possible. But gets called before that. Or perhaps acpi should simply be setup to be the first system device? Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown
Andrew Morton <[EMAIL PROTECTED]> writes: > Pavel Machek <[EMAIL PROTECTED]> wrote: > > > > In `subj` kernel, machine no longer powers down at the end of > > swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk. > > Binary searching indicates that this is due to > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/broken-out/acpi_power_off-bug-fix.patch. > > > I'll drop it. That patch is pretty ugly-looking anyway (ACPI code in > drivers/base/power/?). > > Perhaps someone who is hitting the problem which that patch addresses could > raise a bugzilla entry. > > Oh. It has one. http://bugme.osdl.org/show_bug.cgi?id=4041 > > Anyway. It needs more work. Agreed. I threw it together to test a specific code path, and the fact it fails in software suspend is actually almost confirmation that I am on the right track. This actually fixed the case I was testing. In this case the failure is simply because system_state is not set to SYSTEM_POWER_OFF before kernel/power/disk.c:power_down() calls device_shutdown(). The appropriate reboot notifier is also not called.. So to fix this properly all of the places that call machine_power_off now need to call a wrapper that does all of the appropriate things and then calls machine_power_off. Likewise with the other reboot functions. In addition a clean way to get device_shutdown() to call acpi_power_off_prepare() at roughly the location I have it hard coded. The fundamental issue this patch was starting to address before I ran out of steam, is that acpi_power_off_prepare() must be called with interrupts enabled and after we have shut down the system devices (i.e. the interrupt controllers) we can't guarantee interrupts, are working. I'm don't know how much earlier it is safe to acpi_power_off_prepare(). But mostly I think we need to throw in a fake device to attach acpi_power_off_prepare to. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown
Hi! > Resume on SMP locks up. Does it work on UP kernel on same hardware? NMI watchdog is problem for suspend, it takes long to do various phases. Can you disable it for testing? Pavel > Relocating pagedir | > Reading image data (8157 pages): 100% 8157 done. > Stopping tasks: | > Freeing memory... done (0 pages freed) > Freezing CPUs (at 1)...Sleeping in: > [] dump_stack+0x19/0x20 > [] smp_pause+0x1f/0x54 > [] smp_call_function_interrupt+0x3b/0x60 > [] call_function_interrupt+0x1c/0x24 > [] cpu_idle+0x55/0x64 > [] start_secondary+0x71/0x78 > [<>] 0x0 > [] 0xcffa5fbc > ok > double fault, gdt at c1203260 [255 bytes] > NMI Watchdog detected LOCKUP on CPU1, eip c0133c96, registers: > Modules linked in: video thermal processor pcc_acpi fan button battery ac > CPU:1 > EIP:0060:[]Not tainted VLI > EFLAGS: 0002 (2.6.11-rc5) > EIP is at smp_pause+0x36/0x54 > eax: 0001 ebx: cffa5f20 ecx: fffbe4e6 edx: cffa5f20 > esi: cffa4000 edi: 0080 ebp: cffa5f58 esp: cffa5f1c > ds: 007b es: 007b ss: 0068 > Process swapper (pid: 0, threadinfo=cffa4000 task=c18ac540) > Stack: 007b 0068 80050033 005d3000 06f0 > 00ff0001 >c120b260 07ff5f4c c0577000 0088 cffa0080 c011eed4 cffa5f68 > cffa5f68 >c010ee27 0001 cffa5fa4 c01037d4 0001 c120b260 > fffbe4e5 > Call Trace: > > [] show_stack+0x7b/0x88 > [] show_registers+0x112/0x188 > [] die_nmi+0x41/0x74 > [] nmi_watchdog_tick+0x54/0xcc > [] default_do_nmi+0x73/0xfc > [] do_nmi+0x39/0x4c > [] nmi_stack_correct+0x1d/0x2a > [] smp_call_function_interrupt+0x3b/0x60 > [] call_function_interrupt+0x1c/0x24 > [] cpu_idle+0x55/0x64 > [] start_secondary+0x71/0x78 > [<>] 0x0 > [] 0xcffa5fbc > Code: e8 60 e0 24 00 68 0c 7a 40 c0 e8 c2 68 fe ff e8 85 ff fc ff 83 c4 08 f0 > ff 05 4c 20 5e c0 a1 50 20 5e c0 89 da 85 c0 74 0b f3 > console shuts up ... > > -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown
Hi! > > In `subj` kernel, machine no longer powers down at the end of > > swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk. > > Binary searching indicates that this is due to > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/broken-out/acpi_power_off-bug-fix.patch. > > I'll drop it. That patch is pretty ugly-looking anyway (ACPI code in > drivers/base/power/?). > > Perhaps someone who is hitting the problem which that patch addresses could > raise a bugzilla entry. > > Oh. It has one. http://bugme.osdl.org/show_bug.cgi?id=4041 > > Anyway. It needs more work. Yes, the patch is very ugly. If something like this needs to be done, then perhaps acpi should properly register into driver model and do the work there. This will also mean code will be called consistently. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown
Hi! > btw, suspend is a bit messy. The disk spins down. Then up. Then down > again. And: Yes, that's known, pm_message_t needs to become struct to solve disk pingpong properly. > Debug: sleeping function called from invalid context at mm/slab.c:2082 > in_atomic():0, irqs_disabled():1 > [] dump_stack+0x19/0x20 > [] __might_sleep+0x91/0x9c > [] kmem_cache_alloc+0x23/0x84 > [] acpi_evaluate_integer+0x3c/0xac > [] acpi_bus_get_status+0x39/0x94 > [] acpi_pci_link_set+0x16d/0x1e8 > [] acpi_pci_link_resume+0x1d/0x28 > [] irqrouter_resume+0x1a/0x38 > [] sysdev_resume+0x2c/0xae > [] device_power_up+0x8/0x11 > [] swsusp_suspend+0x4b/0x58 > [] pm_suspend_disk+0x35/0x74 > [] enter_state+0x2e/0x70 > [] software_suspend+0xa/0x10 > [] acpi_system_write_sleep+0x73/0x98 > [] vfs_write+0xaf/0x118 > [] sys_write+0x3c/0x68 > [] sysenter_past_esp+0x52/0x75 ACPI problem, patches are available (s/GFP_KERNEL/GFP_ATOMIC), but Len claims better solution is ready... OTOH he claims that for half a year already so we may push him a bit (added to cc). > Powering off system > Debug: sleeping function called from invalid context at > include/linux/rwsem.h:66 > in_atomic():0, irqs_disabled():1 > > [] dump_stack+0x19/0x20 > [] __might_sleep+0x91/0x9c > [] device_shutdown+0x16/0x82 > [] power_down+0x47/0x74 > [] pm_suspend_disk+0x5a/0x74 > [] enter_state+0x2e/0x70 > [] software_suspend+0xa/0x10 > [] acpi_system_write_sleep+0x73/0x98 > [] vfs_write+0xaf/0x118 > [] sys_write+0x3c/0x68 > [] sysenter_past_esp+0x52/0x75 I'll look at this one. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown
Resume on SMP locks up. Relocating pagedir | Reading image data (8157 pages): 100% 8157 done. Stopping tasks: | Freeing memory... done (0 pages freed) Freezing CPUs (at 1)...Sleeping in: [] dump_stack+0x19/0x20 [] smp_pause+0x1f/0x54 [] smp_call_function_interrupt+0x3b/0x60 [] call_function_interrupt+0x1c/0x24 [] cpu_idle+0x55/0x64 [] start_secondary+0x71/0x78 [<>] 0x0 [] 0xcffa5fbc ok double fault, gdt at c1203260 [255 bytes] NMI Watchdog detected LOCKUP on CPU1, eip c0133c96, registers: Modules linked in: video thermal processor pcc_acpi fan button battery ac CPU:1 EIP:0060:[]Not tainted VLI EFLAGS: 0002 (2.6.11-rc5) EIP is at smp_pause+0x36/0x54 eax: 0001 ebx: cffa5f20 ecx: fffbe4e6 edx: cffa5f20 esi: cffa4000 edi: 0080 ebp: cffa5f58 esp: cffa5f1c ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=cffa4000 task=c18ac540) Stack: 007b 0068 80050033 005d3000 06f0 00ff0001 c120b260 07ff5f4c c0577000 0088 cffa0080 c011eed4 cffa5f68 cffa5f68 c010ee27 0001 cffa5fa4 c01037d4 0001 c120b260 fffbe4e5 Call Trace: [] show_stack+0x7b/0x88 [] show_registers+0x112/0x188 [] die_nmi+0x41/0x74 [] nmi_watchdog_tick+0x54/0xcc [] default_do_nmi+0x73/0xfc [] do_nmi+0x39/0x4c [] nmi_stack_correct+0x1d/0x2a [] smp_call_function_interrupt+0x3b/0x60 [] call_function_interrupt+0x1c/0x24 [] cpu_idle+0x55/0x64 [] start_secondary+0x71/0x78 [<>] 0x0 [] 0xcffa5fbc Code: e8 60 e0 24 00 68 0c 7a 40 c0 e8 c2 68 fe ff e8 85 ff fc ff 83 c4 08 f0 ff 05 4c 20 5e c0 a1 50 20 5e c0 89 da 85 c0 74 0b f3 console shuts up ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown
btw, suspend is a bit messy. The disk spins down. Then up. Then down again. And: Stopping tasks: ==| Freeing memory... done (7069 pages freed) swsusp: Need to copy 7847 pages swsusp: critical section/: done (7879 pages copied) swsusp: Restoring Highmem Debug: sleeping function called from invalid context at mm/slab.c:2082 in_atomic():0, irqs_disabled():1 [] dump_stack+0x19/0x20 [] __might_sleep+0x91/0x9c [] kmem_cache_alloc+0x23/0x84 [] acpi_evaluate_integer+0x3c/0xac [] acpi_bus_get_status+0x39/0x94 [] acpi_pci_link_set+0x16d/0x1e8 [] acpi_pci_link_resume+0x1d/0x28 [] irqrouter_resume+0x1a/0x38 [] sysdev_resume+0x2c/0xae [] device_power_up+0x8/0x11 [] swsusp_suspend+0x4b/0x58 [] pm_suspend_disk+0x35/0x74 [] enter_state+0x2e/0x70 [] software_suspend+0xa/0x10 [] acpi_system_write_sleep+0x73/0x98 [] vfs_write+0xaf/0x118 [] sys_write+0x3c/0x68 [] sysenter_past_esp+0x52/0x75 PCI: Setting latency timer of device :00:1f.2 to 64 ACPI: PCI interrupt :00:1f.5[B] -> GSI 9 (level, low) -> IRQ 9 PCI: Setting latency timer of device :00:1f.5 to 64 ACPI: PCI interrupt :01:00.0[A] -> GSI 11 (level, low) -> IRQ 11 ehci_hcd :02:01.2: USB 2.0 restarted, EHCI 0.95, driver 10 Dec 2004 ACPI: PCI interrupt :02:0c.0[A] -> GSI 9 (level, low) -> IRQ 9 e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex Writing data to swap (7879 pages)... done Writing pagedir (31 pages) S| Powering off system Debug: sleeping function called from invalid context at include/linux/rwsem.h:66 in_atomic():0, irqs_disabled():1 [] dump_stack+0x19/0x20 [] __might_sleep+0x91/0x9c [] device_shutdown+0x16/0x82 [] power_down+0x47/0x74 [] pm_suspend_disk+0x5a/0x74 [] enter_state+0x2e/0x70 [] software_suspend+0xa/0x10 [] acpi_system_write_sleep+0x73/0x98 [] vfs_write+0xaf/0x118 [] sys_write+0x3c/0x68 [] sysenter_past_esp+0x52/0x75 Synchronizing SCSI cache for disk sda: Shutdown: hda acpi_power_off called - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown
Pavel Machek <[EMAIL PROTECTED]> wrote: > > In `subj` kernel, machine no longer powers down at the end of > swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk. Binary searching indicates that this is due to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/broken-out/acpi_power_off-bug-fix.patch. I'll drop it. That patch is pretty ugly-looking anyway (ACPI code in drivers/base/power/?). Perhaps someone who is hitting the problem which that patch addresses could raise a bugzilla entry. Oh. It has one. http://bugme.osdl.org/show_bug.cgi?id=4041 Anyway. It needs more work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 - pcmcia weirdness/breakage
On Mon, 28 Feb 2005 14:48:20 EST, [EMAIL PROTECTED] said: > Symptoms: Running '/etc/init.d/pcmcia start' bombs - cardmgr goes into > a loop spewing repeated 'Common memory region at 0x0: Generic or SRAM' > messages. In the dmesg, we find: > [4294859.369000] cs: unable to map card memory! > [4294859.369000] cs: unable to map card memory! I backed the bk-pci.patch out, and it started working again, so the problem is somewhere in there (progress - we've got it down to one 5,500 patch ;). Perhaps related, the following compile warnings also went away: CC [M] drivers/ieee1394/ohci1394.o drivers/ieee1394/ohci1394.c: In function `ohci_initialize': drivers/ieee1394/ohci1394.c:589: warning: long unsigned int format, different type arg (arg 7) drivers/ieee1394/ohci1394.c:589: warning: long unsigned int format, different type arg (arg 8) drivers/ieee1394/ohci1394.c: In function `ohci1394_pci_probe': drivers/ieee1394/ohci1394.c:3266: warning: long unsigned int format, different type arg (arg 4) CC drivers/pci/rom.o drivers/pci/rom.c: In function `pci_map_rom': drivers/pci/rom.c:74: warning: cast to pointer from integer of different size drivers/pci/rom.c: In function `pci_map_rom_copy': drivers/pci/rom.c:160: warning: cast to pointer from integer of different size drivers/pci/rom.c:164: warning: cast to pointer from integer of different size drivers/pci/rom.c: In function `pci_cleanup_rom': drivers/pci/rom.c:217: warning: cast to pointer from integer of different size CC [M] drivers/pcmcia/rsrc_nonstatic.o drivers/pcmcia/rsrc_nonstatic.c: In function `nonstatic_find_io_region': drivers/pcmcia/rsrc_nonstatic.c:629: warning: passing arg 7 of `pci_bus_alloc_resource' from incompatible pointer type drivers/pcmcia/rsrc_nonstatic.c:633: warning: passing arg 7 of `allocate_resource' from incompatible pointer type drivers/pcmcia/rsrc_nonstatic.c: In function `nonstatic_find_mem_region': drivers/pcmcia/rsrc_nonstatic.c:672: warning: passing arg 7 of `pci_bus_alloc_resource' from incompatible pointer type drivers/pcmcia/rsrc_nonstatic.c:676: warning: passing arg 7 of `allocate_resource' from incompatible pointer type I'm suspicious of the warnings for rsrc_nonstatic.o, because we end up in that exact piece of code just before failing with the 'unable to map card memory' message. Maybe that arg 7 is causing us to pass a stack that doesn't quite match what's expected, and thus the bug? pgpKsNXw53T66.pgp Description: PGP signature
Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown
Le 01.03.2005 00:17, Pavel Machek a écrit : Hi! In `subj` kernel, machine no longer powers down at the end of swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk. Pavel Hello, I noticed this behaviour, too. Can't remember if it came with 2.6.11-rc3-mm2 or with 2.6.11-rc4-mm1. Didn't try another kernel. I was able to workaround this problem by doing "echo platform > /sys/power/disk" before "echo disk > /sys/power/state" The box is a desktop with an asus A7V133 mb (VIA 82Cxxx chipset), Athlon XP 1600+ CPU and NVidia Geforce2 MX400 graphics. ~~ laurent signature.asc Description: OpenPGP digital signature
Re: 2.6.11-rc4-mm1 - pcmcia weirdness/breakage
On Mon, 28 Feb 2005 21:22:26 +0100, Dominik Brodowski said: > On Mon, Feb 28, 2005 at 02:48:20PM -0500, [EMAIL PROTECTED] wrote: > > A full -rc4-mm1 fails, *as does* a -rc4-mm1 with all the following patches > > -R'ed: ... > > broken-out/pcmcia-bridge-resource-management-fix.patch > > So the breakage is in *some other* -rc4-mm1 patch. Any hints to speed up > > the binary search? > > Most likely it's > pcmcia-bridge-resource-management-fix.patch I'd believe you, except that patch has already been -R'ed and I'm still seeing the problem. That's why I'm mystified - I backed out all the obvious culprits already, and the problem's still there... pgpWLWkkG59ZC.pgp Description: PGP signature
Re: 2.6.11-rc4-mm1 - pcmcia weirdness/breakage
On Mon, Feb 28, 2005 at 02:48:20PM -0500, [EMAIL PROTECTED] wrote: > Symptoms: Running '/etc/init.d/pcmcia start' bombs - cardmgr goes into > a loop spewing repeated 'Common memory region at 0x0: Generic or SRAM' > messages. In the dmesg, we find: > > [4294764.989000] <6>cs: IO port probe 0xc00-0xcff: clean. > [4294859.195000] cs: IO port probe 0xc00-0xcff: clean. > [4294859.195000] cs: IO port probe 0xc00-0xcff: clean. > [4294859.199000] cs: IO port probe 0x100-0x4ff: excluding 0x170-0x177 > 0x370-0x37f > [4294859.202000] cs: IO port probe 0x100-0x4ff: excluding 0x170-0x177 > 0x370-0x37f > [4294859.205000] cs: IO port probe 0x100-0x4ff: excluding 0x170-0x177 > 0x370-0x37f > [4294859.207000] cs: IO port probe 0xa00-0xaff: clean. > [4294859.208000] cs: IO port probe 0xa00-0xaff: clean. > [4294859.209000] cs: IO port probe 0xa00-0xaff: clean. > [4294859.369000] cs: unable to map card memory! > [4294859.369000] cs: unable to map card memory! > > Now the odd part: > > 2.6.11-rc4 works, doesn't show the last 2 'unable to map' messages. > 2.6.11-rc4 + linus.patch from -rc4-mm1 works as well - so it's a -mm patch > doing it. > > A full -rc4-mm1 fails, *as does* a -rc4-mm1 with all the following patches > -R'ed: > > broken-out/fix-u32-vs-pm_message_t-confusion-in-pcmcia.patch > broken-out/pcmcia-add-pcmcia-devices-autonomously.patch > broken-out/pcmcia-bridge-resource-management-fix.patch > broken-out/pcmcia-determine-some-useful-information-about-devices.patch > broken-out/pcmcia-mark-resource-setup-as-done.patch > broken-out/pcmcia-pcmcia_device_add.patch > broken-out/pcmcia-pcmcia_device_probe.patch > broken-out/pcmcia-pcmcia_device_remove.patch > broken-out/pcmcia-pd6729-convert-to-pci_register_driver.patch > broken-out/pcmcia-per-device-sysfs-output.patch > broken-out/pcmcia-rsrc_nonstatic-sysfs-input.patch > broken-out/pcmcia-rsrc_nonstatic-sysfs-output.patch > broken-out/pcmcia-update-vrc4171_card.patch > broken-out/pcmcia-use-bus_rescan_devices.patch > broken-out/pcmcia-yenta_socket-ti4150-support.patch > > So the breakage is in *some other* -rc4-mm1 patch. Any hints to speed up > the binary search? Most likely it's pcmcia-bridge-resource-management-fix.patch Dominik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 patch] drivers/scsi/arcmsr/arcmsr.c cleanups
On Sun, Feb 27, 2005 at 04:48:10PM +0100, Adrian Bunk wrote: > - aren't the "if defined(__x86_64__)" wrong for other 64bit > architectures? Yes. Having arch or 64bit ifdefs is pretty wrong pretty much always. In one case it's only used to make a typedef a 32bit or 64bit integeger, that should be using unsigned long directly always, but the other uses looks like real problems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1
On Thursday 24 February 2005 19:06, J.A. Magallon wrote: > > On 02.24, Dmitry Torokhov wrote: > > On Wednesday 23 February 2005 18:12, Ed Tomlinson wrote: > > > On Wednesday 23 February 2005 17:38, J.A. Magallon wrote: > > > > > > > > On 02.23, Andrew Morton wrote: > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ > > > > > > > > > > > > > > > - Various fixes and updates all over the place. Things seem to have > > > > > slowed > > > > > down a bit. > > > > > > > > > > - Last, final, ultimate call: if anyone has patches in here which are > > > > > 2.6.11 > > > > > material, please tell me. > > > > > > > > > > > > > Two points: > > > > > > > > - I lost my keyboard :(. USB, but plugged into PS/2 with an adapter. > > > > > > Mine too. Details sent in another message... > > > > > > > Does i8042.nopnp help? > > > > Yes, that makes things work. > Even better than ever before, now an USB mouse and a PS/2 logitech > trackball work fine both at the same time. In console and in X. > In previous kernels PS/2 was dead or jumped heavily when an usb mouse > was plugged. The keyboard works both in PS/2 (with adapter) and in USB. > > Now a tricky question: the mouse and the trackball move the pointer in X > at different speeds. Is there any way to tell the kernel they have > the same DPI ? Or can I tweak the speed/DPI settings for them separately > to get a more or less similar movement ? > You can try changing PS/2 mouse rate and resolution via the following sysfs attributes: /sys/bus/serio/devices/serioX/rate /sys/bus/serio/devices/serioX/resolution like this: echo -n "200" > /sys/bus/serio/devices/serio1/resolution Or you could try setting both mice as separate devices in X... -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 (VFS: Cannot open root device "301")
On Wed, 23 Feb 2005 16:25:39 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > Could someone try this?
>
> Let's turn that into a real patch.
>
> --- 25/drivers/ide/ide-probe.c~ide_init_disk-fixWed Feb 23 16:24:44
> 2005
> +++ 25-akpm/drivers/ide/ide-probe.c Wed Feb 23 16:24:55 2005
> @@ -1269,7 +1269,7 @@ EXPORT_SYMBOL_GPL(ide_unregister_region)
> void ide_init_disk(struct gendisk *disk, ide_drive_t *drive)
> {
> ide_hwif_t *hwif = drive->hwif;
> - unsigned int unit = drive->select.all & (1 << 4);
> + unsigned int unit = (drive->select.all >> 4) & 1;
>
> disk->major = hwif->major;
> disk->first_minor = unit << PARTN_BITS;
> _
>
> -
Works for me.
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1
On 02.24, Dmitry Torokhov wrote: > On Wednesday 23 February 2005 18:12, Ed Tomlinson wrote: > > On Wednesday 23 February 2005 17:38, J.A. Magallon wrote: > > > > > > On 02.23, Andrew Morton wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ > > > > > > > > > > > > - Various fixes and updates all over the place. Things seem to have > > > > slowed > > > > down a bit. > > > > > > > > - Last, final, ultimate call: if anyone has patches in here which are > > > > 2.6.11 > > > > material, please tell me. > > > > > > > > > > Two points: > > > > > > - I lost my keyboard :(. USB, but plugged into PS/2 with an adapter. > > > > Mine too. Details sent in another message... > > > > Does i8042.nopnp help? > Yes, that makes things work. Even better than ever before, now an USB mouse and a PS/2 logitech trackball work fine both at the same time. In console and in X. In previous kernels PS/2 was dead or jumped heavily when an usb mouse was plugged. The keyboard works both in PS/2 (with adapter) and in USB. Now a tricky question: the mouse and the trackball move the pointer in X at different speeds. Is there any way to tell the kernel they have the same DPI ? Or can I tweak the speed/DPI settings for them separately to get a more or less similar movement ? TIA -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrakelinux release 10.2 (Cooker) for i586 Linux 2.6.10-jam11 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
On Thu, Feb 24, 2005 at 09:42:24PM +0100, Laurent Riffard wrote: > I do need device-mapper, since I put /usr and /var on LVM filesystems. I > use ptkcdvd to copy data to CD-RW. I can remove this one. > > Anyway, this patch from Andrew fixed the problem : > http://lkml.org/lkml/2005/2/23/214. Yeah, it's not in my code! :) > So I won't try to remove pktcdvd and device-mapper driver (except if you > _really_ want me to do so). Nope, as long as the above patch works for you, I'm happy. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
Le 24.02.2005 18:18, Greg KH a écrit : On Thu, Feb 24, 2005 at 06:06:39PM +0100, Laurent Riffard wrote: Le 24.02.2005 00:47, Greg KH a ?crit : On Wed, Feb 23, 2005 at 11:36:50PM +0100, Laurent Riffard wrote: hey, what's this /dev/hds ? digging into /sys/block... ~$ ls -l /sys/block/hds/device lrwxrwxrwx 1 root root 0 f?v 23 22:45 /sys/block/hds/device -> ../../devices/pci:00/:00:04.1/ide1/1.1/ /dev/hdq should be /dev/hdd... ~$ ls -l /proc/ide total 4 -r--r--r-- 1 root root 0 f?v 23 23:28 drivers lrwxrwxrwx 1 root root 8 f?v 23 23:28 hda -> ide0/hda/ lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdb -> ide0/hdb/ lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdc -> ide1/hdc/ lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdd -> ide1/hdd/ dr-xr-xr-x 4 root root 0 f?v 23 23:28 ide0/ dr-xr-xr-x 4 root root 0 f?v 23 23:28 ide1/ -r--r--r-- 1 root root 0 f?v 23 23:28 via ~$ ls -d /sys/block/hd* /sys/block/hda/ /sys/block/hdc/ /sys/block/hdq/ /sys/block/hds/ What does /proc/devices show? Character devices: 1 mem 4 /dev/vc/0 4 tty 5 /dev/tty 5 /dev/console 5 /dev/ptmx 6 lp 7 vcs 10 misc 13 input 14 sound 29 fb 116 alsa 128 ptm 136 pts 171 ieee1394 180 usb Block devices: 1 ramdisk 2 fd 3 ide0 7 loop 22 ide1 253 pktcdvd 254 device-mapper Do you see something strange here ? No, ide0 is 3 and ide1 is 22, which is "standard". Hm, what's that pktcdvd and device-mapper doing there? Do you need those drivers? Can you try it without building them and see if that helps? I do need device-mapper, since I put /usr and /var on LVM filesystems. I use ptkcdvd to copy data to CD-RW. I can remove this one. Anyway, this patch from Andrew fixed the problem : http://lkml.org/lkml/2005/2/23/214. So I won't try to remove pktcdvd and device-mapper driver (except if you _really_ want me to do so). Thanks for your interest. -- laurent signature.asc Description: OpenPGP digital signature
Re: 2.6.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
On Thu, Feb 24, 2005 at 06:06:39PM +0100, Laurent Riffard wrote: > > > Le 24.02.2005 00:47, Greg KH a ?crit : > >On Wed, Feb 23, 2005 at 11:36:50PM +0100, Laurent Riffard wrote: > > > >>hey, what's this /dev/hds ? digging into /sys/block... > >> > >>~$ ls -l /sys/block/hds/device > >>lrwxrwxrwx 1 root root 0 f?v 23 22:45 /sys/block/hds/device -> > >>../../devices/pci:00/:00:04.1/ide1/1.1/ > >> > >>/dev/hdq should be /dev/hdd... > >> > >>~$ ls -l /proc/ide > >>total 4 > >>-r--r--r-- 1 root root 0 f?v 23 23:28 drivers > >>lrwxrwxrwx 1 root root 8 f?v 23 23:28 hda -> ide0/hda/ > >>lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdb -> ide0/hdb/ > >>lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdc -> ide1/hdc/ > >>lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdd -> ide1/hdd/ > >>dr-xr-xr-x 4 root root 0 f?v 23 23:28 ide0/ > >>dr-xr-xr-x 4 root root 0 f?v 23 23:28 ide1/ > >>-r--r--r-- 1 root root 0 f?v 23 23:28 via > >>~$ ls -d /sys/block/hd* > >>/sys/block/hda/ /sys/block/hdc/ /sys/block/hdq/ /sys/block/hds/ > > > > > >What does /proc/devices show? > > Character devices: > 1 mem > 4 /dev/vc/0 > 4 tty > 5 /dev/tty > 5 /dev/console > 5 /dev/ptmx > 6 lp > 7 vcs > 10 misc > 13 input > 14 sound > 29 fb > 116 alsa > 128 ptm > 136 pts > 171 ieee1394 > 180 usb > > Block devices: > 1 ramdisk > 2 fd > 3 ide0 > 7 loop > 22 ide1 > 253 pktcdvd > 254 device-mapper > > Do you see something strange here ? No, ide0 is 3 and ide1 is 22, which is "standard". Hm, what's that pktcdvd and device-mapper doing there? Do you need those drivers? Can you try it without building them and see if that helps? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
Le 24.02.2005 00:47, Greg KH a écrit : On Wed, Feb 23, 2005 at 11:36:50PM +0100, Laurent Riffard wrote: hey, what's this /dev/hds ? digging into /sys/block... ~$ ls -l /sys/block/hds/device lrwxrwxrwx 1 root root 0 f?v 23 22:45 /sys/block/hds/device -> ../../devices/pci:00/:00:04.1/ide1/1.1/ /dev/hdq should be /dev/hdd... ~$ ls -l /proc/ide total 4 -r--r--r-- 1 root root 0 f?v 23 23:28 drivers lrwxrwxrwx 1 root root 8 f?v 23 23:28 hda -> ide0/hda/ lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdb -> ide0/hdb/ lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdc -> ide1/hdc/ lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdd -> ide1/hdd/ dr-xr-xr-x 4 root root 0 f?v 23 23:28 ide0/ dr-xr-xr-x 4 root root 0 f?v 23 23:28 ide1/ -r--r--r-- 1 root root 0 f?v 23 23:28 via ~$ ls -d /sys/block/hd* /sys/block/hda/ /sys/block/hdc/ /sys/block/hdq/ /sys/block/hds/ What does /proc/devices show? Character devices: 1 mem 4 /dev/vc/0 4 tty 5 /dev/tty 5 /dev/console 5 /dev/ptmx 6 lp 7 vcs 10 misc 13 input 14 sound 29 fb 116 alsa 128 ptm 136 pts 171 ieee1394 180 usb Block devices: 1 ramdisk 2 fd 3 ide0 7 loop 22 ide1 253 pktcdvd 254 device-mapper Do you see something strange here ? -- laurent signature.asc Description: OpenPGP digital signature
Re: 2.6.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
Le 24.02.2005 00:20, Andrew Morton a écrit : Laurent Riffard <[EMAIL PROTECTED]> wrote: Le 23.02.2005 21:12, Andrew Morton a écrit : Helge Hafting <[EMAIL PROTECTED]> wrote: This kernel came up, but my boot script complained about no /dev/hdb3 when trying to mount /var. (I have two IDE disks on the same cable, and an IDE cdrom on another.) They are usually hda, hdb, and hdc. MAKEDEV hdq did not help. Looking at sysfs, it turns out that /dev/hdq1 is at major:3 minor:1025 if I interpret things right. (/dev/hda1 is at 3:1, which is correct.) These numbers did not work with my mknod, it created 7:1 instead. So I didn't get to test this mysterious device. But I assume this is a mistake of some sort, I haven't heard about any change in the IDE numbering coming up? 2.6.1-rc3-mm1 works as expected. It may be interesting to note that my root raid-1 came up fine, consisting of hdq1 and hda1 instead of the usual hdb1 and hda1. I don't know what could be causing that. Please send .config. If you set CONFIG_BASE_FULL=n, try setting it to `y'. this is just a "me too"... Confusing. Are you saying that the hdd->hdq problem is happening even with CONFIG_BASE_FULL=y? yes, I do. -- laurent signature.asc Description: OpenPGP digital signature
Re: 2.6.11-rc4-mm1 (VFS: Cannot open root device "301")
Matt Mackall wrote:
On Wed, Feb 23, 2005 at 03:10:38PM -0700, Steven Cole wrote:
Andrew Morton wrote:
Steven Cole <[EMAIL PROTECTED]> wrote:
I am having trouble getting recent -mm kernels to boot on my test box.
For 2.6.11-rc3-mm2 and 2.6.11-rc4-mm1 I get the following:
VFS: Cannot open root device "301" or unknown-block(3,1)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(3,1)
[snipped]
Please set CONFIG_BASE_FULL=y. Check that this causes CONFIG_BASE_SMALL=0,
then retest.
Yes, that worked. 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be
missing.
Can you retry CONFIG_BASE_FULL=n with Andrew's patch?
You may need to boot back into a sane kernel for LILO to operate properly.
--- 25/drivers/ide/ide-probe.c~ide_init_disk-fix Wed Feb 23 16:24:44 2005
+++ 25-akpm/drivers/ide/ide-probe.c Wed Feb 23 16:24:55 2005
@@ -1269,7 +1269,7 @@ EXPORT_SYMBOL_GPL(ide_unregister_region)
void ide_init_disk(struct gendisk *disk, ide_drive_t *drive)
{
ide_hwif_t *hwif = drive->hwif;
- unsigned int unit = drive->select.all & (1 << 4);
+ unsigned int unit = (drive->select.all >> 4) & 1;
disk->major = hwif->major;
disk->first_minor = unit << PARTN_BITS;
Andrew's above patch fixes the hdb->hdq insanity, but I still need
CONFIG_BASE_FULL=y. I tried unsetting CONFIG_BASE_FULL, and again
got the "VFS: Cannot open root device" message (with akpm's patch).
Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.11-rc4-mm1 (VFS: Cannot open root device "301")
Matt Mackall wrote:
On Wed, Feb 23, 2005 at 03:10:38PM -0700, Steven Cole wrote:
Andrew Morton wrote:
Steven Cole <[EMAIL PROTECTED]> wrote:
I am having trouble getting recent -mm kernels to boot on my test box.
For 2.6.11-rc3-mm2 and 2.6.11-rc4-mm1 I get the following:
VFS: Cannot open root device "301" or unknown-block(3,1)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(3,1)
[snipped]
Please set CONFIG_BASE_FULL=y. Check that this causes CONFIG_BASE_SMALL=0,
then retest.
Yes, that worked. 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be
missing.
Can you retry CONFIG_BASE_FULL=n with Andrew's patch?
You may need to boot back into a sane kernel for LILO to operate properly.
--- 25/drivers/ide/ide-probe.c~ide_init_disk-fix Wed Feb 23 16:24:44 2005
+++ 25-akpm/drivers/ide/ide-probe.c Wed Feb 23 16:24:55 2005
@@ -1269,7 +1269,7 @@ EXPORT_SYMBOL_GPL(ide_unregister_region)
void ide_init_disk(struct gendisk *disk, ide_drive_t *drive)
{
ide_hwif_t *hwif = drive->hwif;
- unsigned int unit = drive->select.all & (1 << 4);
+ unsigned int unit = (drive->select.all >> 4) & 1;
disk->major = hwif->major;
disk->first_minor = unit << PARTN_BITS;
Andrew's above patch fixes the hdb->hdq insanity, but I still need
CONFIG_BASE_FULL=y. I tried unsetting CONFIG_BASE_FULL, and again
got the "VFS: Cannot open root device" message (with akpm's patch).
Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.11-rc4-mm1 (VFS: Cannot open root device "301")
On Wed, 23 Feb 2005 16:25:39 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > Could someone try this?
>
> Let's turn that into a real patch.
>
> --- 25/drivers/ide/ide-probe.c~ide_init_disk-fixWed Feb 23 16:24:44
> 2005
> +++ 25-akpm/drivers/ide/ide-probe.c Wed Feb 23 16:24:55 2005
> @@ -1269,7 +1269,7 @@ EXPORT_SYMBOL_GPL(ide_unregister_region)
> void ide_init_disk(struct gendisk *disk, ide_drive_t *drive)
> {
> ide_hwif_t *hwif = drive->hwif;
> - unsigned int unit = drive->select.all & (1 << 4);
> + unsigned int unit = (drive->select.all >> 4) & 1;
>
> disk->major = hwif->major;
> disk->first_minor = unit << PARTN_BITS;
thanks Andrew
fscking bitfields hopefully viro will kill them soon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1 (VFS: Cannot open root device "301")
On Thu, Feb 24, 2005 at 03:03:33AM +0100, Benoit Boissinot wrote:
> On Wed, 23 Feb 2005 16:41:59 -0800, Matt Mackall <[EMAIL PROTECTED]> wrote:
> > On Wed, Feb 23, 2005 at 04:16:53PM -0800, Andrew Morton wrote:
> > > Steven Cole <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Yes, that worked. 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be
> > > > > missing.
> > >
> > > Looking at the IDE update in rc4-mm1:
> > >
> > > +void ide_init_disk(struct gendisk *disk, ide_drive_t *drive)
> > > +{
> > > + ide_hwif_t *hwif = drive->hwif;
> > > + unsigned int unit = drive->select.all & (1 << 4);
> > > +
>
> If i grep in the tree, for select.all, it looks like from the initialization
> that you can not recover the unit from select.all (ide.c line 235 and 1882)
> since the function used is not invertible.
They're fine, if a bit ugly. Unit is either 0 or 1. So:
(unit<<4) | 0xa0
is equivalent to unit * 16 as the mask won't mask off any bits.
> > >
> > > Could someone try this?
> > >
> > > - unsigned int unit = drive->select.all & (1 << 4);
> > > + unsigned int unit = (drive->select.all >> 4) & 1;
> >
> > Apparently there's already an 'hdb' sitting in drive->name, perhaps we
> > ought to do disk->disk_name = drive->name for the non-devfs case.
> >
> init_hwif_default initialized it right.
>
> Could something like this work ?
No, because they're arrays and not pointers. I've booted with the
obvious strcpy, works fine.
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1 (VFS: Cannot open root device "301")
On Wed, 23 Feb 2005 16:41:59 -0800, Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 23, 2005 at 04:16:53PM -0800, Andrew Morton wrote:
> > Steven Cole <[EMAIL PROTECTED]> wrote:
> > >
> > > > Yes, that worked. 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be
> > > > missing.
> >
> > Looking at the IDE update in rc4-mm1:
> >
> > +void ide_init_disk(struct gendisk *disk, ide_drive_t *drive)
> > +{
> > + ide_hwif_t *hwif = drive->hwif;
> > + unsigned int unit = drive->select.all & (1 << 4);
> > +
If i grep in the tree, for select.all, it looks like from the initialization
that you can not recover the unit from select.all (ide.c line 235 and 1882)
since the function used is not invertible.
> >
> > Could someone try this?
> >
> > - unsigned int unit = drive->select.all & (1 << 4);
> > + unsigned int unit = (drive->select.all >> 4) & 1;
>
> Apparently there's already an 'hdb' sitting in drive->name, perhaps we
> ought to do disk->disk_name = drive->name for the non-devfs case.
>
init_hwif_default initialized it right.
Could something like this work ?
regards,
Benoit
--- linux/drivers/ide/ide-probe.c 2005-02-23 12:16:32.0 +0100
+++ linux-test/drivers/ide/ide-probe.c 2005-02-24 03:02:06.0 +0100
@@ -1269,11 +1269,11 @@ EXPORT_SYMBOL_GPL(ide_unregister_region)
void ide_init_disk(struct gendisk *disk, ide_drive_t *drive)
{
ide_hwif_t *hwif = drive->hwif;
- unsigned int unit = drive->select.all & (1 << 4);
+ unsigned int unit = drive->name[2] - 'a' - hwif->index * MAX_DRIVES;
disk->major = hwif->major;
disk->first_minor = unit << PARTN_BITS;
- sprintf(disk->disk_name, "hd%c", 'a' + hwif->index * MAX_DRIVES + unit);
+ disk->disk_name = drive->name;
disk->queue = drive->queue;
}
Re: 2.6.11-rc4-mm1 (VFS: Cannot open root device "301")
On Wed, Feb 23, 2005 at 03:10:38PM -0700, Steven Cole wrote:
> Andrew Morton wrote:
> >Steven Cole <[EMAIL PROTECTED]> wrote:
>
> >>I am having trouble getting recent -mm kernels to boot on my test box.
> >>For 2.6.11-rc3-mm2 and 2.6.11-rc4-mm1 I get the following:
> >>
> >>VFS: Cannot open root device "301" or unknown-block(3,1)
> >>Please append a correct "root=" boot option
> >>Kernel panic - not syncing: VFS: Unable to mount root fs on
> >>unknown-block(3,1)
> >>
> [snipped]
> >
> >Please set CONFIG_BASE_FULL=y. Check that this causes CONFIG_BASE_SMALL=0,
> >then retest.
>
> Yes, that worked. 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be
> missing.
Can you retry CONFIG_BASE_FULL=n with Andrew's patch?
You may need to boot back into a sane kernel for LILO to operate properly.
--- 25/drivers/ide/ide-probe.c~ide_init_disk-fixWed Feb 23 16:24:44 2005
+++ 25-akpm/drivers/ide/ide-probe.c Wed Feb 23 16:24:55 2005
@@ -1269,7 +1269,7 @@ EXPORT_SYMBOL_GPL(ide_unregister_region)
void ide_init_disk(struct gendisk *disk, ide_drive_t *drive)
{
ide_hwif_t *hwif = drive->hwif;
- unsigned int unit = drive->select.all & (1 << 4);
+ unsigned int unit = (drive->select.all >> 4) & 1;
disk->major = hwif->major;
disk->first_minor = unit << PARTN_BITS;
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1 (VFS: Cannot open root device "301")
Steven Cole <[EMAIL PROTECTED]> wrote: > > Andrew Morton wrote: > > Steven Cole <[EMAIL PROTECTED]> wrote: > > >> I am having trouble getting recent -mm kernels to boot on my test box. > >> For 2.6.11-rc3-mm2 and 2.6.11-rc4-mm1 I get the following: > >> > >> VFS: Cannot open root device "301" or unknown-block(3,1) > >> Please append a correct "root=" boot option > >> Kernel panic - not syncing: VFS: Unable to mount root fs on > >> unknown-block(3,1) > >> > [snipped] > > > > Please set CONFIG_BASE_FULL=y. Check that this causes CONFIG_BASE_SMALL=0, > > then retest. > > Yes, that worked. hmm, OK. Matt, we have a block major enumeration problem. It appears that base-small-shrink-chrdevs-hash.patch has the same problem which base-small-shrink-major_names-hash.patch had. > 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be missing. > > [EMAIL PROTECTED] steven]# uname -r > 2.6.11-rc4-mm1-GX110 > [EMAIL PROTECTED] steven]# mount -t reiser4 /dev/hdb1 /reiser4_testing > mount: special device /dev/hdb1 does not exist It would seem that your /dev/hdb1 block-special device node isn't present. Try `mknod /dev/hdb1 3 65'. > hdb: max request size: 128KiB > hdb: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(66) > hdb: cache flushes not supported > /dev/ide/host0/bus0/target1/lun0: p1 We found a partition. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 (VFS: Cannot open root device "301")
On Wed, Feb 23, 2005 at 04:16:53PM -0800, Andrew Morton wrote:
> Steven Cole <[EMAIL PROTECTED]> wrote:
> >
> > > Yes, that worked. 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be
> > > missing.
>
> Looking at the IDE update in rc4-mm1:
>
> +void ide_init_disk(struct gendisk *disk, ide_drive_t *drive)
> +{
> + ide_hwif_t *hwif = drive->hwif;
> + unsigned int unit = drive->select.all & (1 << 4);
> +
> + disk->major = hwif->major;
> + disk->first_minor = unit << PARTN_BITS;
> + sprintf(disk->disk_name, "hd%c", 'a' + hwif->index * MAX_DRIVES + unit);
> + disk->queue = drive->queue;
> +}
>
> Looks funny.
>
> Could someone try this?
>
> - unsigned int unit = drive->select.all & (1 << 4);
> + unsigned int unit = (drive->select.all >> 4) & 1;
Apparently there's already an 'hdb' sitting in drive->name, perhaps we
ought to do disk->disk_name = drive->name for the non-devfs case.
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1
On Wednesday 23 February 2005 18:40, Dmitry Torokhov wrote: > On Wednesday 23 February 2005 18:12, Ed Tomlinson wrote: > > On Wednesday 23 February 2005 17:38, J.A. Magallon wrote: > > > > > > On 02.23, Andrew Morton wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ > > > > > > > > > > > > - Various fixes and updates all over the place. Things seem to have > > > > slowed > > > > down a bit. > > > > > > > > - Last, final, ultimate call: if anyone has patches in here which are > > > > 2.6.11 > > > > material, please tell me. > > > > > > > > > > Two points: > > > > > > - I lost my keyboard :(. USB, but plugged into PS/2 with an adapter. > > > > Mine too. Details sent in another message... > > > > Does i8042.nopnp help? Dmitry, Yes it works fine with this kernel parm. I run with hotplug on and udev off. Andrew, 11-bk is also fine (without the parm). Thanks Ed Tomlinson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1
Dmitry Torokhov a ecrit le 24.02.2005 00:40: On Wednesday 23 February 2005 18:12, Ed Tomlinson wrote: On Wednesday 23 February 2005 17:38, J.A. Magallon wrote: On 02.23, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ - Various fixes and updates all over the place. Things seem to have slowed down a bit. - Last, final, ultimate call: if anyone has patches in here which are 2.6.11 material, please tell me. Two points: - I lost my keyboard :(. USB, but plugged into PS/2 with an adapter. Mine too. Details sent in another message... Does i8042.nopnp help? yes, keyboard is back Andrew Morton a ecrit le 24.02.2005 00:25: Ed Tomlinson <[EMAIL PROTECTED]> wrote: It does not seem to be finding the keyboard at all... Can you confirm that Linus's tree is OK? You'd best use the patch at http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/ to make sure you have the latest stuff. 2.6.11-rc4 + http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/cset-20050223_2308.txt.gz is indeed ok : Feb 24 01:08:23 odie kernel: Kernel command line: BOOT_IMAGE=2.6.11-rc4-ff ro root=305 hdd=ide-scsi [...] Feb 24 01:08:23 odie kernel: input: AT Translated Set 2 keyboard on isa0060/serio0 Thank you, Fabian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 (VFS: Cannot open root device "301")
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Could someone try this?
Let's turn that into a real patch.
--- 25/drivers/ide/ide-probe.c~ide_init_disk-fixWed Feb 23 16:24:44 2005
+++ 25-akpm/drivers/ide/ide-probe.c Wed Feb 23 16:24:55 2005
@@ -1269,7 +1269,7 @@ EXPORT_SYMBOL_GPL(ide_unregister_region)
void ide_init_disk(struct gendisk *disk, ide_drive_t *drive)
{
ide_hwif_t *hwif = drive->hwif;
- unsigned int unit = drive->select.all & (1 << 4);
+ unsigned int unit = (drive->select.all >> 4) & 1;
disk->major = hwif->major;
disk->first_minor = unit << PARTN_BITS;
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
On Thu, Feb 24, 2005 at 12:32:59AM +0100, Mathieu Segaud wrote: > Andrew Morton <[EMAIL PROTECTED]> disait derni??rement que : > > > Helge Hafting <[EMAIL PROTECTED]> wrote: > >> > >> This kernel came up, but my boot script complained about no /dev/hdb3 > >> when trying to mount /var. > >> (I have two IDE disks on the same cable, and an IDE cdrom on another.) > >> They are usually hda, hdb, and hdc. > >> > >> MAKEDEV hdq did not help. Looking at sysfs, it turns out that > >> /dev/hdq1 is at major:3 minor:1025 if I interpret things right. > >> (/dev/hda1 is at 3:1, which is correct.) > >> These numbers did not work with my mknod, it created 7:1 instead. > >> So I didn't get to test this mysterious device. > >> > >> But I assume this is a mistake of some sort, I haven't heard about any > >> change in the IDE numbering coming up? 2.6.1-rc3-mm1 works as expected. > >> > >> It may be interesting to note that my root raid-1 came up fine, > >> consisting of hdq1 and hda1 instead of the usual hdb1 and hda1. > > > > I don't know what could be causing that. Please send .config. If you set > > CONFIG_BASE_FULL=n, try setting it to `y'. > > I've got the same problem here on my box, udev creates hds and hdu > entries when running 2.6.11-rc4-mm1, whereas it creates correctly hdf > et hdh, on other kernels. Are these misnamed and misnumbered devices mountable? If not, can you mknod device nodes at the proper major:minor location and have them work? Seems ->disk_name is getting modified between ide_setup() and add_disk() somehow, giving us: hdb: ... hdq: hdq1 hdq2... -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1 (VFS: Cannot open root device "301")
Steven Cole <[EMAIL PROTECTED]> wrote:
>
> > Yes, that worked. 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be
> > missing.
Looking at the IDE update in rc4-mm1:
+void ide_init_disk(struct gendisk *disk, ide_drive_t *drive)
+{
+ ide_hwif_t *hwif = drive->hwif;
+ unsigned int unit = drive->select.all & (1 << 4);
+
+ disk->major = hwif->major;
+ disk->first_minor = unit << PARTN_BITS;
+ sprintf(disk->disk_name, "hd%c", 'a' + hwif->index * MAX_DRIVES + unit);
+ disk->queue = drive->queue;
+}
Looks funny.
Could someone try this?
- unsigned int unit = drive->select.all & (1 << 4);
+ unsigned int unit = (drive->select.all >> 4) & 1;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
On Wed, Feb 23, 2005 at 11:36:50PM +0100, Laurent Riffard wrote: > hey, what's this /dev/hds ? digging into /sys/block... > > ~$ ls -l /sys/block/hds/device > lrwxrwxrwx 1 root root 0 f?v 23 22:45 /sys/block/hds/device -> > ../../devices/pci:00/:00:04.1/ide1/1.1/ > > /dev/hdq should be /dev/hdd... > > ~$ ls -l /proc/ide > total 4 > -r--r--r-- 1 root root 0 f?v 23 23:28 drivers > lrwxrwxrwx 1 root root 8 f?v 23 23:28 hda -> ide0/hda/ > lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdb -> ide0/hdb/ > lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdc -> ide1/hdc/ > lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdd -> ide1/hdd/ > dr-xr-xr-x 4 root root 0 f?v 23 23:28 ide0/ > dr-xr-xr-x 4 root root 0 f?v 23 23:28 ide1/ > -r--r--r-- 1 root root 0 f?v 23 23:28 via > ~$ ls -d /sys/block/hd* > /sys/block/hda/ /sys/block/hdc/ /sys/block/hdq/ /sys/block/hds/ What does /proc/devices show? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1
Dominik Brodowski a écrit : +pcmcia-bridge-resource-management-fix.patch is responsible for this "no resource available" message, because the other ones relate to other areas. This line from dmesg-2.6.11-rc4 is no longer present in -rc4-mm1: PCI: Transparent bridge - :00:1e.0 This is probably due to this patch too, right ? Was it supposed to changed that ? lspci -tv says that the PCMCIA bridge whose resources are broken is behind this no-longer transparent bridge. -[00]-+-00.0 Intel Corp. 82830 830 Chipset Host Bridge +-01.0-[01]00.0 ATI Technologies Inc Radeon Mobility M6 LY +-1d.0 Intel Corp. 82801CA/CAM USB (Hub #1) +-1d.1 Intel Corp. 82801CA/CAM USB (Hub #2) +-1d.2 Intel Corp. 82801CA/CAM USB (Hub #3) +-1e.0-[02-04]--+-03.0 Texas Instruments PCI1420 | +-03.1 Texas Instruments PCI1420 | +-04.0 Agere Systems (former Lucent Microelectronics) LT WinModem | +-08.0 Intel Corp. 82801CAM (ICH3) PRO/100 VM (KM) Ethernet Controller | \-09.0 ESS Technology ES1988 Allegro-1 +-1f.0 Intel Corp. 82801CAM ISA Bridge (LPC) \-1f.1 Intel Corp. 82801CAM IDE U100 Hope this helps. Brice - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1
On Wednesday 23 February 2005 18:12, Ed Tomlinson wrote: > On Wednesday 23 February 2005 17:38, J.A. Magallon wrote: > > > > On 02.23, Andrew Morton wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ > > > > > > > > > - Various fixes and updates all over the place. Things seem to have > > > slowed > > > down a bit. > > > > > > - Last, final, ultimate call: if anyone has patches in here which are > > > 2.6.11 > > > material, please tell me. > > > > > > > Two points: > > > > - I lost my keyboard :(. USB, but plugged into PS/2 with an adapter. > > Mine too. Details sent in another message... > Does i8042.nopnp help? -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
Andrew Morton <[EMAIL PROTECTED]> disait derniÃrement que : > Helge Hafting <[EMAIL PROTECTED]> wrote: >> >> This kernel came up, but my boot script complained about no /dev/hdb3 >> when trying to mount /var. >> (I have two IDE disks on the same cable, and an IDE cdrom on another.) >> They are usually hda, hdb, and hdc. >> >> MAKEDEV hdq did not help. Looking at sysfs, it turns out that >> /dev/hdq1 is at major:3 minor:1025 if I interpret things right. >> (/dev/hda1 is at 3:1, which is correct.) >> These numbers did not work with my mknod, it created 7:1 instead. >> So I didn't get to test this mysterious device. >> >> But I assume this is a mistake of some sort, I haven't heard about any >> change in the IDE numbering coming up? 2.6.1-rc3-mm1 works as expected. >> >> It may be interesting to note that my root raid-1 came up fine, >> consisting of hdq1 and hda1 instead of the usual hdb1 and hda1. > > I don't know what could be causing that. Please send .config. If you set > CONFIG_BASE_FULL=n, try setting it to `y'. I've got the same problem here on my box, udev creates hds and hdu entries when running 2.6.11-rc4-mm1, whereas it creates correctly hdf et hdh, on other kernels. here follows .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc4-mm1 # Wed Feb 23 22:11:44 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_BASE_SMALL=0 CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y # CONFIG_HPET_TIMER is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=m # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_HIGHPTE=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y CONFIG_SECCOMP=y # # Performance-monitoring counters support # # CONFIG_PERFCTR is not set CONFIG_PHYSICAL_START=0x10 CONFIG_KEXEC=y # # Power management options (ACPI, APM) # # CONFIG_PM is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m # CONFIG_ACPI_VIDEO is not set CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_PCC=m CONFIG_ACPI_SONY=m CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BU
Re: 2.6.11-rc4-mm1
On Wednesday 23 February 2005 04:42, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ > > > - Various fixes and updates all over the place. Things seem to have slowed > down a bit. > > - Last, final, ultimate call: if anyone has patches in here which are 2.6.11 > material, please tell me. It boots fine here except that my keyboard is dead, rc3-mm2 is fine. The .config was built via using rc3-mm2's config and make oldconfig. Looking it the boot log I see: in rc3-mm2 Feb 23 17:49:20 grover kernel: Initializing Cryptographic API Feb 23 17:49:20 grover kernel: Linux agpgart interface v0.101 (c) Dave Jones Feb 23 17:49:20 grover kernel: [drm] Initialized drm 1.0.0 20040925 Feb 23 17:49:20 grover kernel: ACPI: PS/2 Keyboard Controller [PS2K] at I/O 0x60, 0x64, irq 1 Feb 23 17:49:20 grover kernel: ACPI: PS/2 Mouse Controller [PS2M] at irq 12 Feb 23 17:49:20 grover kernel: serio: i8042 AUX port at 0x60,0x64 irq 12 Feb 23 17:49:20 grover kernel: serio: i8042 KBD port at 0x60,0x64 irq 1 Feb 23 17:49:20 grover kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled in rc4-mm1 Feb 23 17:46:54 grover kernel: Initializing Cryptographic API Feb 23 17:46:54 grover kernel: inotify device minor=63 Feb 23 17:46:54 grover kernel: Linux agpgart interface v0.101 (c) Dave Jones Feb 23 17:46:54 grover kernel: [drm] Initialized drm 1.0.0 20040925 Feb 23 17:46:54 grover kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled Feb 23 17:46:54 grover kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A It does not seem to be finding the keyboard at all... Ideas? Ed Tomlinson diff -u ../11-3-2/.config .config --- ../11-3-2/.config 2005-02-12 09:55:28.0 -0500 +++ .config 2005-02-23 07:10:53.0 -0500 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.11-rc3-mm2 -# Sat Feb 12 09:55:28 2005 +# Linux kernel version: 2.6.11-rc4-mm1 +# Wed Feb 23 07:10:53 2005 # CONFIG_X86_64=y CONFIG_64BIT=y @@ -91,6 +91,7 @@ CONFIG_X86_MCE_INTEL=y CONFIG_PHYSICAL_START=0x10 CONFIG_KEXEC=y +CONFIG_SECCOMP=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y @@ -119,6 +120,8 @@ CONFIG_ACPI_ASUS=m # CONFIG_ACPI_IBM is not set CONFIG_ACPI_TOSHIBA=m +# CONFIG_ACPI_PCC is not set +# CONFIG_ACPI_SONY is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y @@ -459,6 +462,7 @@ CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m +# CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs @@ -493,6 +497,7 @@ # CONFIG_SCSI_ATA_PIIX is not set CONFIG_SCSI_SATA_NV=m # CONFIG_SCSI_SATA_PROMISE is not set +# CONFIG_SCSI_SATA_QSTOR is not set # CONFIG_SCSI_SATA_SX4 is not set # CONFIG_SCSI_SATA_SIL is not set # CONFIG_SCSI_SATA_SIS is not set @@ -543,6 +548,8 @@ CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m CONFIG_DM_ZERO=m +CONFIG_DM_MULTIPATH=m +CONFIG_DM_MULTIPATH_EMC=m # # Fusion MPT device support @@ -971,6 +978,11 @@ CONFIG_BT_HCIBPA10X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIVHCI=m +CONFIG_IEEE80211=m +# CONFIG_IEEE80211_DEBUG is not set +CONFIG_IEEE80211_CRYPT_WEP=m +CONFIG_IEEE80211_CRYPT_CCMP=m +CONFIG_IEEE80211_CRYPT_TKIP=m CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_BONDING=m @@ -1263,6 +1275,8 @@ # CONFIG_JOYSTICK_JOYDUMP is not set CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_GUNZE=m +# CONFIG_TOUCHSCREEN_ELO is not set +# CONFIG_TOUCHSCREEN_MK712 is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m CONFIG_INPUT_UINPUT=m @@ -1293,6 +1307,7 @@ CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y +CONFIG_INOTIFY=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_COMPUTONE=m CONFIG_ROCKETPORT=m @@ -1370,6 +1385,7 @@ CONFIG_IB700_WDT=m CONFIG_WAFER_WDT=m CONFIG_I8XX_TCO=m +# CONFIG_I6300ESB_WDT is not set CONFIG_SC1200_WDT=m CONFIG_SCx200_WDT=m CONFIG_60XX_WDT=m @@ -1444,6 +1460,11 @@ CONFIG_HANGCHECK_TIMER=m # +# TPM devices +# +# CONFIG_TCG_TPM is not set + +# # I2C support # CONFIG_I2C=m @@ -1471,6 +1492,7 @@ CONFIG_I2C_NFORCE2=m CONFIG_I2C_PARPORT=m CONFIG_I2C_PARPORT_LIGHT=m +# CONFIG_I2C_PIIX4 is not set CONFIG_I2C_PROSAVAGE=m CONFIG_I2C_SAVAGE4=m CONFIG_SCx200_ACB=m @@ -1496,6 +1518,7 @@ CONFIG_SENSORS_FSCHER=m # CONFIG_SENSORS_FSCPOS is not set CONFIG_SENSORS_GL518SM=m +CONFIG_SENSORS_GL520SM=m CONFIG_SENSORS_IT87=m # CONFIG_SENSORS_LM63 is not set CONFIG_SENSORS_LM75=m @@ -1509,6 +1532,7 @@ CONFIG_SENSORS_MAX1619=m # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_SMSC47B397 is not set +CONFIG_SENSORS_SIS5595=m # CONFIG_SENSORS_SMSC47M1 is not set CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_W83781D=m @@ -1682,6 +1706,10 @@ # Graphics support # CONFIG_FB=y +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_IMAGEBLIT=y +CONFIG_FB_SOFT_CURSOR=y CONFIG_FB_MODE_HELPERS=y # CONFIG_FB_TILE
Re: 2.6.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
Laurent Riffard <[EMAIL PROTECTED]> wrote: > > Le 23.02.2005 21:12, Andrew Morton a écrit : > > Helge Hafting <[EMAIL PROTECTED]> wrote: > > > >>This kernel came up, but my boot script complained about no /dev/hdb3 > >> when trying to mount /var. > >> (I have two IDE disks on the same cable, and an IDE cdrom on another.) > >> They are usually hda, hdb, and hdc. > >> > >> MAKEDEV hdq did not help. Looking at sysfs, it turns out that > >> /dev/hdq1 is at major:3 minor:1025 if I interpret things right. > >> (/dev/hda1 is at 3:1, which is correct.) > >> These numbers did not work with my mknod, it created 7:1 instead. > >> So I didn't get to test this mysterious device. > >> > >> But I assume this is a mistake of some sort, I haven't heard about any > >> change in the IDE numbering coming up? 2.6.1-rc3-mm1 works as expected. > >> > >> It may be interesting to note that my root raid-1 came up fine, > >> consisting of hdq1 and hda1 instead of the usual hdb1 and hda1. > > > > > > I don't know what could be causing that. Please send .config. If you set > > CONFIG_BASE_FULL=n, try setting it to `y'. > > > > this is just a "me too"... Confusing. Are you saying that the hdd->hdq problem is happening even with CONFIG_BASE_FULL=y? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1
Ed Tomlinson <[EMAIL PROTECTED]> wrote: > > It does not seem to be finding the keyboard at all... Can you confirm that Linus's tree is OK? You'd best use the patch at http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/ to make sure you have the latest stuff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1
On Wednesday 23 February 2005 17:38, J.A. Magallon wrote: > > On 02.23, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ > > > > > > - Various fixes and updates all over the place. Things seem to have slowed > > down a bit. > > > > - Last, final, ultimate call: if anyone has patches in here which are 2.6.11 > > material, please tell me. > > > > Two points: > > - I lost my keyboard :(. USB, but plugged into PS/2 with an adapter. Mine too. Details sent in another message... Ed > - hdb is missing. initscripts show an strange message about hdq ?? > As I read the same on other post, I think something has screwed the > ide device naming scheme ... > > TIA > > -- > J.A. Magallon \ Software is like sex: > werewolf!able!es \ It's better when it's free > Mandrakelinux release 10.2 (Cooker) for i586 > Linux 2.6.10-jam10 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #2 > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
On Wed, Feb 23, 2005 at 11:36:50PM +0100, Laurent Riffard wrote: > Le 23.02.2005 21:12, Andrew Morton a ?crit : > >Helge Hafting <[EMAIL PROTECTED]> wrote: > > > >>This kernel came up, but my boot script complained about no /dev/hdb3 > >>when trying to mount /var. > >>(I have two IDE disks on the same cable, and an IDE cdrom on another.) > >>They are usually hda, hdb, and hdc. > >> > >>MAKEDEV hdq did not help. Looking at sysfs, it turns out that > >>/dev/hdq1 is at major:3 minor:1025 if I interpret things right. > >>(/dev/hda1 is at 3:1, which is correct.) > >>These numbers did not work with my mknod, it created 7:1 instead. > >>So I didn't get to test this mysterious device. > >> > >>But I assume this is a mistake of some sort, I haven't heard about any > >>change in the IDE numbering coming up? 2.6.1-rc3-mm1 works as expected. > >> > >>It may be interesting to note that my root raid-1 came up fine, > >>consisting of hdq1 and hda1 instead of the usual hdb1 and hda1. > > > > > >I don't know what could be causing that. Please send .config. If you set > >CONFIG_BASE_FULL=n, try setting it to `y'. > > > > this is just a "me too"... > > Here is some few lines from dmesg : > > hdb: cache flushes supported > hdq: hdq1 hdq2 < hdq5 hdq6 hdq7 hdq8 > Neat. > ~$ ls -l /dev/hd* > brw-rw 1 rootdisk 3,0 f?v 23 22:45 /dev/hda > brw-rw 1 rootdisk 3,1 f?v 23 22:45 /dev/hda1 > brw-rw 1 rootdisk 3, 10 f?v 23 22:45 /dev/hda10 > brw-rw 1 rootdisk 3,2 f?v 23 22:45 /dev/hda2 > brw-rw 1 rootdisk 3,3 f?v 23 22:45 /dev/hda3 > brw-rw 1 rootdisk 3,4 f?v 23 22:45 /dev/hda4 > brw-rw 1 rootdisk 3,5 f?v 23 22:45 /dev/hda5 > brw-rw 1 rootdisk 3,6 f?v 23 22:45 /dev/hda6 > brw-rw 1 rootdisk 3,7 f?v 23 22:45 /dev/hda7 > brw-rw 1 rootdisk 3,8 f?v 23 22:45 /dev/hda8 > brw-rw 1 rootdisk 3,9 f?v 23 22:45 /dev/hda9 > brw-rw 1 laurent cdrom 22,0 f?v 23 22:45 /dev/hdc > brw--- 1 rootroot 22, 64 f?v 23 22:45 /dev/hdd > brw-rw 1 rootdisk 3, 1024 f?v 23 22:45 /dev/hdq Looks like you're using udev. > CONFIG_BASE_FULL=y > CONFIG_BASE_SMALL=0 Ok, that's unrelated to the weird IDE numbering then. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1 (VFS: Cannot open root device "301")
On Wed, Feb 23, 2005 at 03:03:33PM -0800, Andrew Morton wrote: > Steven Cole <[EMAIL PROTECTED]> wrote: > > > > Andrew Morton wrote: > > > Steven Cole <[EMAIL PROTECTED]> wrote: > > > > >> I am having trouble getting recent -mm kernels to boot on my test box. > > >> For 2.6.11-rc3-mm2 and 2.6.11-rc4-mm1 I get the following: > > >> > > >> VFS: Cannot open root device "301" or unknown-block(3,1) > > >> Please append a correct "root=" boot option > > >> Kernel panic - not syncing: VFS: Unable to mount root fs on > > >> unknown-block(3,1) > > >> > > [snipped] > > > > > > Please set CONFIG_BASE_FULL=y. Check that this causes > > > CONFIG_BASE_SMALL=0, > > > then retest. > > > > Yes, that worked. > > hmm, OK. Matt, we have a block major enumeration problem. It appears that > base-small-shrink-chrdevs-hash.patch has the same problem which > base-small-shrink-major_names-hash.patch had. Hard to see how that could happen. > > 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be missing. > > > > [EMAIL PROTECTED] steven]# uname -r > > 2.6.11-rc4-mm1-GX110 > > [EMAIL PROTECTED] steven]# mount -t reiser4 /dev/hdb1 /reiser4_testing > > mount: special device /dev/hdb1 does not exist > > It would seem that your /dev/hdb1 block-special device node isn't present. > Try `mknod /dev/hdb1 3 65'. He's got devfs. Something change there recently? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1 (VFS: Cannot open root device "301")
Steven Cole wrote: Andrew Morton wrote: Steven Cole <[EMAIL PROTECTED]> wrote: I am having trouble getting recent -mm kernels to boot on my test box. For 2.6.11-rc3-mm2 and 2.6.11-rc4-mm1 I get the following: VFS: Cannot open root device "301" or unknown-block(3,1) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,1) [snipped] Please set CONFIG_BASE_FULL=y. Check that this causes CONFIG_BASE_SMALL=0, then retest. Yes, that worked. 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be missing. [EMAIL PROTECTED] steven]# uname -r 2.6.11-rc4-mm1-GX110 [EMAIL PROTECTED] steven]# mount -t reiser4 /dev/hdb1 /reiser4_testing mount: special device /dev/hdb1 does not exist Reading another post (and looking in /dev), I tried hdq: [EMAIL PROTECTED] steven]# mount -t reiser4 /dev/hdq1 /reiser4_testing [EMAIL PROTECTED] steven]# df -T FilesystemTypeSize Used Avail Use% Mounted on /dev/hda1 ext3304M 75M 214M 26% / /dev/hda9 reiserfs8.3G 3.9G 4.4G 48% /home /dev/hda8 ext3464M 8.1M 432M 2% /tmp /dev/hda6 ext37.4G 1.7G 5.4G 24% /usr /dev/hda7 ext31.9G 86M 1.7G 5% /var /dev/hdq1 reiser4 18G 217M 18G 2% /reiser4_testing Snipped from dmesg: hda: ST320423A, ATA DISK drive hdb: WDC WD200BB-75AUA1, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: SONY CD-RW CRX160E, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 Probing IDE interface ide2... Probing IDE interface ide3... Probing IDE interface ide4... Probing IDE interface ide5... hda: max request size: 128KiB hda: 40011300 sectors (20485 MB) w/512KiB Cache, CHS=39693/16/63, UDMA(66) hda: cache flushes not supported /dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 p7 p8 p9 > hdb: max request size: 128KiB hdb: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(66) hdb: cache flushes not supported /dev/ide/host0/bus0/target1/lun0: p1 Steven (Replying to myself) I decided to fix 2.6.11-rc3-mm1 with CONFIG_BASE_FULL=y and see if the hdb/hdq confusion existed with that earlier kernel, but when I ran lilo, I got a "Fatal: cache_add: LILO internal error" message. [EMAIL PROTECTED] steven]# /sbin/lilo -v LILO version 22.6.1, Copyright (C) 1992-1998 Werner Almesberger Development beyond version 21 Copyright (C) 1999-2004 John Coffman Released 17-Nov-2004, and compiled at 20:03:17 on Jan 15 2005 Reading boot sector from /dev/hda Fatal: cache_add: LILO internal error This box is still running 2.6.11-rc4-mm1 from above, and was booted with append="root=0301" accidentally left in lilo.conf from earlier testing. Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 (VFS: Cannot open root device "301")
On Wed, Feb 23, 2005 at 09:37:53AM -0700, Steven Cole wrote: > I copied a working .config from an earlier kernel(-rc3), and ran make > oldconfig, answering most of the new questions 'n'. Then you get into trouble with stuff under CONFIG_EMBEDDED. Answering 'n' turns off stock functionality. Though you really ought not have CONFIG_EMBEDDED turned on anyway. I'm not sure how CONFIG_BASE_SMALL is causing problems as the blockdev bit got dropped already. I'll poke around.. Andrew, looks like turning on EMBEDDED causes a bunch of options to spill onto the general setup menu in menuconfig because of the placement of the bool piece: Fix up bustedness in menuconfig Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> Index: mm1/init/Kconfig === --- mm1.orig/init/Kconfig 2005-02-23 13:32:38.0 -0800 +++ mm1/init/Kconfig2005-02-23 14:27:18.699676896 -0800 @@ -274,11 +274,6 @@ config BASE_FULL Disabling this option reduces the size of miscellaneous core kernel data structures. -config BASE_SMALL - int - default 0 if BASE_FULL - default 1 if !BASE_FULL - config FUTEX bool "Enable futex support" if EMBEDDED default y @@ -360,6 +355,11 @@ config TINY_SHMEM default !SHMEM bool +config BASE_SMALL + int + default 0 if BASE_FULL + default 1 if !BASE_FULL + menu "Loadable module support" config MODULES -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1
On 02.23, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ > > > - Various fixes and updates all over the place. Things seem to have slowed > down a bit. > > - Last, final, ultimate call: if anyone has patches in here which are 2.6.11 > material, please tell me. > Two points: - I lost my keyboard :(. USB, but plugged into PS/2 with an adapter. - hdb is missing. initscripts show an strange message about hdq ?? As I read the same on other post, I think something has screwed the ide device naming scheme ... TIA -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrakelinux release 10.2 (Cooker) for i586 Linux 2.6.10-jam10 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
Le 23.02.2005 21:12, Andrew Morton a écrit : Helge Hafting <[EMAIL PROTECTED]> wrote: This kernel came up, but my boot script complained about no /dev/hdb3 when trying to mount /var. (I have two IDE disks on the same cable, and an IDE cdrom on another.) They are usually hda, hdb, and hdc. MAKEDEV hdq did not help. Looking at sysfs, it turns out that /dev/hdq1 is at major:3 minor:1025 if I interpret things right. (/dev/hda1 is at 3:1, which is correct.) These numbers did not work with my mknod, it created 7:1 instead. So I didn't get to test this mysterious device. But I assume this is a mistake of some sort, I haven't heard about any change in the IDE numbering coming up? 2.6.1-rc3-mm1 works as expected. It may be interesting to note that my root raid-1 came up fine, consisting of hdq1 and hda1 instead of the usual hdb1 and hda1. I don't know what could be causing that. Please send .config. If you set CONFIG_BASE_FULL=n, try setting it to `y'. this is just a "me too"... Here is some few lines from dmesg : Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot :00:04.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci:00:04.1 ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA Probing IDE interface ide0... hda: ST340016A, ATA DISK drive hdb: Maxtor 6Y080L0, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: CD-950E/AKU, ATAPI CD/DVD-ROM drive hdd: LITE-ON LTR-48125S, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 Probing IDE interface ide2... Probing IDE interface ide3... Probing IDE interface ide4... Probing IDE interface ide5... hda: max request size: 128KiB hda: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100) hda: cache flushes not supported hda: hda1 hda2 hda3 < hda5 hda6 hda7 hda8 hda9 hda10 > hda4 hdb: max request size: 128KiB hdb: 160086528 sectors (81964 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100) hdb: cache flushes supported hdq: hdq1 hdq2 < hdq5 hdq6 hdq7 hdq8 > ~$ ls -l /dev/hd* brw-rw 1 rootdisk 3,0 fév 23 22:45 /dev/hda brw-rw 1 rootdisk 3,1 fév 23 22:45 /dev/hda1 brw-rw 1 rootdisk 3, 10 fév 23 22:45 /dev/hda10 brw-rw 1 rootdisk 3,2 fév 23 22:45 /dev/hda2 brw-rw 1 rootdisk 3,3 fév 23 22:45 /dev/hda3 brw-rw 1 rootdisk 3,4 fév 23 22:45 /dev/hda4 brw-rw 1 rootdisk 3,5 fév 23 22:45 /dev/hda5 brw-rw 1 rootdisk 3,6 fév 23 22:45 /dev/hda6 brw-rw 1 rootdisk 3,7 fév 23 22:45 /dev/hda7 brw-rw 1 rootdisk 3,8 fév 23 22:45 /dev/hda8 brw-rw 1 rootdisk 3,9 fév 23 22:45 /dev/hda9 brw-rw 1 laurent cdrom 22,0 fév 23 22:45 /dev/hdc brw--- 1 rootroot 22, 64 fév 23 22:45 /dev/hdd brw-rw 1 rootdisk 3, 1024 fév 23 22:45 /dev/hdq brw-rw 1 rootdisk 3, 1025 fév 23 22:45 /dev/hdq1 brw-rw 1 rootdisk 3, 1026 fév 23 22:45 /dev/hdq2 brw-rw 1 rootdisk 3, 1029 fév 23 22:45 /dev/hdq5 brw-rw 1 rootdisk 3, 1030 fév 23 22:45 /dev/hdq6 brw-rw 1 rootdisk 3, 1031 fév 23 22:45 /dev/hdq7 brw-rw 1 rootdisk 3, 1032 fév 23 22:45 /dev/hdq8 brw-rw 1 rootdisk 22, 1024 fév 23 22:45 /dev/hds /dev/hdq should be /dev/hdb. hey, what's this /dev/hds ? digging into /sys/block... ~$ ls -l /sys/block/hds/device lrwxrwxrwx 1 root root 0 fév 23 22:45 /sys/block/hds/device -> ../../devices/pci:00/:00:04.1/ide1/1.1/ /dev/hdq should be /dev/hdd... ~$ ls -l /proc/ide total 4 -r--r--r-- 1 root root 0 fév 23 23:28 drivers lrwxrwxrwx 1 root root 8 fév 23 23:28 hda -> ide0/hda/ lrwxrwxrwx 1 root root 8 fév 23 23:28 hdb -> ide0/hdb/ lrwxrwxrwx 1 root root 8 fév 23 23:28 hdc -> ide1/hdc/ lrwxrwxrwx 1 root root 8 fév 23 23:28 hdd -> ide1/hdd/ dr-xr-xr-x 4 root root 0 fév 23 23:28 ide0/ dr-xr-xr-x 4 root root 0 fév 23 23:28 ide1/ -r--r--r-- 1 root root 0 fév 23 23:28 via ~$ ls -d /sys/block/hd* /sys/block/hda/ /sys/block/hdc/ /sys/block/hdq/ /sys/block/hds/ .config is attached ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc4-mm1 # Wed Feb 23 21:30:41 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONF
Re: 2.6.11-rc4-mm1
Andrew Morton <[EMAIL PROTECTED]> : [...] > - Last, final, ultimate call: if anyone has patches in here which are 2.6.11 > material, please tell me. Any chance to convince the alien who took control of Jeff's libata queue to push: r8169: synchronization and balancing when the device is closed (1.1982.1.58 ?) Test case on current 2.6.11-rc4: - ifconfig ethX 10.0.0.1 up - ifconfig ethX down - ifconfig ethX 10.0.0.1 up -> Rx does not work any more - ifconfig ethX down -> command hangs -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 (VFS: Cannot open root device "301")
Andrew Morton wrote: Steven Cole <[EMAIL PROTECTED]> wrote: I am having trouble getting recent -mm kernels to boot on my test box. For 2.6.11-rc3-mm2 and 2.6.11-rc4-mm1 I get the following: VFS: Cannot open root device "301" or unknown-block(3,1) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,1) [snipped] Please set CONFIG_BASE_FULL=y. Check that this causes CONFIG_BASE_SMALL=0, then retest. Yes, that worked. 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be missing. [EMAIL PROTECTED] steven]# uname -r 2.6.11-rc4-mm1-GX110 [EMAIL PROTECTED] steven]# mount -t reiser4 /dev/hdb1 /reiser4_testing mount: special device /dev/hdb1 does not exist Reading another post (and looking in /dev), I tried hdq: [EMAIL PROTECTED] steven]# mount -t reiser4 /dev/hdq1 /reiser4_testing [EMAIL PROTECTED] steven]# df -T FilesystemTypeSize Used Avail Use% Mounted on /dev/hda1 ext3304M 75M 214M 26% / /dev/hda9 reiserfs8.3G 3.9G 4.4G 48% /home /dev/hda8 ext3464M 8.1M 432M 2% /tmp /dev/hda6 ext37.4G 1.7G 5.4G 24% /usr /dev/hda7 ext31.9G 86M 1.7G 5% /var /dev/hdq1 reiser4 18G 217M 18G 2% /reiser4_testing Snipped from dmesg: hda: ST320423A, ATA DISK drive hdb: WDC WD200BB-75AUA1, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: SONY CD-RW CRX160E, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 Probing IDE interface ide2... Probing IDE interface ide3... Probing IDE interface ide4... Probing IDE interface ide5... hda: max request size: 128KiB hda: 40011300 sectors (20485 MB) w/512KiB Cache, CHS=39693/16/63, UDMA(66) hda: cache flushes not supported /dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 p7 p8 p9 > hdb: max request size: 128KiB hdb: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(66) hdb: cache flushes not supported /dev/ide/host0/bus0/target1/lun0: p1 Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1
Dominik Brodowski a écrit : +pcmcia-bridge-resource-management-fix.patch is responsible for this "no resource available" message, because the other ones relate to other areas. Yes, good catch, reverting it makes PCMCIA work again. Let me know if you want me to test some patches. Thanks, Brice - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 (compile stats)
Linux 2.6 (mm tree) Compile Statistics (gcc 3.4.1) Web page with links to complete details: http://developer.osdl.org/cherry/compile/ KernelbzImage bzImage bzImage modules bzImage modules (defconfig) (allno) (allyes) (allyes) (allmod) (allmod) --- -- 2.6.11-rc4-mm1 22w/0e 0w/0e 271w/0e 10w/0e 25w/0e249w/0e 2.6.11-rc3-mm2 14w/0e 0w/0e 192w/0e6w/0e 19w/0e172w/0e 2.6.11-rc3-mm1 13w/10e0w/7e 196w/12e 6w/0e 18w/12e 177w/0e 2.6.11-rc2-mm2 15w/0e 0w/0e 201w/0e6w/0e 18w/0e182w/0e 2.6.11-rc2-mm1 15w/0e 0w/0e 306w/14e 6w/0e 18w/0e294w/0e 2.6.11-rc1-mm2 21w/0e 0w/0e 316w/9e6w/0e 22w/0e294w/0e 2.6.11-rc1-mm1 21w/0e 0w/0e 319w/0e6w/0e 23w/0e298w/0e 2.6.10-mm3 21w/0e 0w/0e 320w/0e6w/0e 23w/0e299w/0e 2.6.10-mm2 21w/0e 0w/0e 440w/0e6w/0e 23w/0e420w/0e 2.6.10-mm1 12w/0e 0w/0e 414w/0e6w/0e 17w/0e399w/0e 2.6.10-rc3-mm1 12w/0e 0w/0e 414w/0e6w/0e 16w/0e401w/0e 2.6.10-rc2-mm4 15w/0e 1w/7e 421w/0e6w/0e 16w/0e408w/0e 2.6.10-rc2-mm3 15w/0e 0w/0e 1255w/12e 66w/0e 16w/0e 1507w/0e 2.6.10-rc2-mm2 15w/0e 0w/0e 1362w/15e 65w/0e 16w/0e 1612w/2e 2.6.10-rc2-mm1 15w/0e 0w/0e 1405w/11e 65w/0e 16w/0e 1652w/0e 2.6.10-rc1-mm5 16w/0e 0w/0e 1587w/0e 65w/0e 20w/0e 1834w/0e 2.6.10-rc1-mm4 16w/0e 0w/0e 1485w/9e 65w/0e 20w/0e 1732w/0e (Compiles with gcc 3.2.2) 2.6.10-rc1-mm37w/31e0w/9e 496w/141e 4w/0e 4w/50e 693w/83e 2.6.10-rc1-mm2 16w/1e 1w/1e 529w/1e4w/0e 12w/1e729w/0e 2.6.10-mm1 12w/0e 0w/0e 414w/0e6w/0e 17w/0e399w/0e 2.6.10-rc3-mm1 12w/0e 0w/0e 414w/0e6w/0e 16w/0e401w/0e 2.6.10-rc2-mm4 15w/0e 1w/7e 421w/0e6w/0e 16w/0e408w/0e 2.6.10-rc2-mm3 15w/0e 0w/0e 1255w/12e 66w/0e 16w/0e 1507w/0e 2.6.10-rc2-mm2 15w/0e 0w/0e 1362w/15e 65w/0e 16w/0e 1612w/2e 2.6.10-rc2-mm1 15w/0e 0w/0e 1405w/11e 65w/0e 16w/0e 1652w/0e 2.6.10-rc1-mm5 16w/0e 0w/0e 1587w/0e 65w/0e 20w/0e 1834w/0e 2.6.10-rc1-mm4 16w/0e 0w/0e 1485w/9e 65w/0e 20w/0e 1732w/0e (Compiles with gcc 3.2.2) 2.6.10-rc1-mm37w/31e0w/9e 496w/141e 4w/0e 4w/50e 693w/83e 2.6.10-rc1-mm2 16w/1e 1w/1e 529w/1e4w/0e 12w/1e729w/0e 2.6.10-rc1-mm1 16w/1e 1w/1e 592w/1e4w/0e 13w/1e857w/0e 2.6.9-mm1 6w/1e 1w/1e 1761w/15e 65w/0e 9w/0e 2086w/0e 2.6.9-rc4-mm1 5w/0e 0w/0e 1766w/11e 43w/0e 6w/0e 1798w/0e 2.6.9-rc3-mm3 5w/0e 0w/0e 1756w/11e 43w/0e 4w/0e 1786w/0e 2.6.9-rc3-mm210w/0e 4w/9e 1754w/14e 43w/0e 4w/0e 1782w/1e 2.6.9-rc3-mm110w/0e 4w/10e 1768w/0e 43w/0e 4w/0e 1796w/0e 2.6.9-rc2-mm410w/0e 5w/0e 2573w/0e 41w/0e 4w/0e 2600w/0e 2.6.9-rc2-mm310w/0e 5w/0e 2400w/0e 41w/0e 4w/0e 2435w/0e 2.6.9-rc2-mm210w/0e 5w/0e 2919w/0e 41w/0e 4w/0e 2954w/0e 2.6.9-rc2-mm1 0w/0e 2w/0e 3541w/9e 41w/0e 3w/9e 3567w/0e 2.6.9-rc1-mm4 0w/0e 1w/0e55w/0e3w/0e 2w/0e 48w/0e 2.6.9-rc1-mm3 0w/0e 0w/0e55w/13e 3w/0e 1w/0e 49w/1e 2.6.9-rc1-mm2 0w/0e 0w/0e53w/11e 3w/0e 1w/0e 47w/0e 2.6.9-rc1-mm1 0w/0e 0w/0e80w/0e4w/0e 1w/0e 74w/0e 2.6.8.1-mm4 0w/0e 0w/0e78w/0e4w/0e 1w/0e 73w/0e 2.6.8.1-mm3 0w/96e0w/0e78w/97e 4w/0e 1w/0e 74w/89e 2.6.8.1-mm2 0w/96e0w/0e78w/97e 4w/0e 1w/0e 74w/89e 2.6.8.1-mm1 0w/0e 0w/0e78w/0e4w/0e 1w/0e 74w/0e 2.6.8-rc4-mm1 0w/0e 0w/5e81w/0e4w/0e 1w/0e 75w/0e 2.6.8-rc3-mm2 1w/7e 0w/5e82w/8e4w/0e 2w/8e 75w/0e 2.6.8-rc3-mm1 0w/0e 1w/5e81w/9e4w/0e 1w/0e 75w/0e 2.6.8-rc2-mm2 0w/0e 4w/5e87w/9e4w/0e 1w/0e 80w/0e 2.6.8-rc2-mm1 0w/0e 0w/0e83w/9e3w/0e 1w/0e 81w/0e 2.6.8-rc1-mm1 0w/0e 0w/0e88w/9e5w/0e 1w/0e 87w/0e 2.6.7-mm7 0w/0e 0w/0e89w/9e5w/0e 1w/0e 84w/0e 2.6.7-mm6 0w/0e 0w/0e85w/9e5w/0e 1w/0e 80w/0e 2.6.7-mm5 0w/0e 0w/0e92w/0e5w/0e 1w/0e 87w/0e 2.6.7-mm4 0w/0e 0w/0e94w/0e5w/0e 1w/0e 89w/0e 2.6.7-mm3 0w/0e 0w/0e90w/6e5w/0e 1w/0e 86w/0e 2.6.7-mm2 0w/0e 0w/0e 109w/0e7w/0e 1w/0e106w/0e 2.6.7-mm1 0w/0e 5w/0e 108w/0e5w/0e 1w/0e104w/0e 2.6.7-rc3-mm2 0w/0e 5w/0e 105w/10e 5w/0e 2w/0e100w/2e 2.6.7-rc3-mm1 0w/0e 5w/0e 104w/10e 5w/0e 2w/0e100w/2e 2.6.7-rc2-mm2 0w/0e 5w/0e 109w/10e 5w/0e 2w/0e105w/2e 2.6.7-rc2-mm1 0w/0e12w/0e 158w/13e 5w/0e
Re: 2.6.11-rc4-mm1
On Wed, Feb 23, 2005 at 01:42:33AM -0800, Andrew Morton wrote: >... > Changes since 2.6.11-rc3-mm1: >... > bk-kbuild.patch >... This adds -Wno-pointer-sign to the main Makefile a second time. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1
Hi, On Wed, Feb 23, 2005 at 07:20:09PM +0100, Brice Goglin wrote: > Andrew Morton a écrit : > >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ > > I can't get PCMCIA to work anymore since rc4-mm1. > It was working great with rc4 and rc3-mm1. > > PCMCIA loads without any apparent problem (see attached dmesg). One thing surprises me: the sockets don't get IO resources allocated: > yenta :02:03.1: no resource of type 100 available, trying to continue... > yenta :02:03.1: no resource of type 100 available, trying to continue... which doesn't happen in earlier kernels. In lspci this shows itself as: I/O window 0: -0003 I/O window 1: -0003 > Which one(s) do you think might be responsible for this ? My gut tells me > >+pcmcia-bridge-resource-management-fix.patch is responsible for this "no resource available" message, because the other ones relate to other areas. If the error persists, it'd be great if you could apply the other PCMCIA patches to the working -rc4 tree and check if it continues to work -- or, the other way round, removing the PCMCIA patches completely and checking whether it works then. Thanks, Dominik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1
On Wed, Feb 23, 2005 at 01:42:33AM -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/
>
>
> - Various fixes and updates all over the place. Things seem to have slowed
> down a bit.
>
> - Last, final, ultimate call: if anyone has patches in here which are 2.6.11
> material, please tell me.
>
>
>
> Changes since 2.6.11-rc3-mm1:
>
> make-itimer_real-per-process.patch
> make ITIMER_REAL per-process
>
> make-itimer_prof-itimer_virtual-per-process.patch
> make ITIMER_PROF, ITIMER_VIRTUAL per-process
>
gcc-4.0 warns with reasons on this patches:
kernel/itimer.c: In function âdo_getitimerâ:
kernel/itimer.c:61: warning: âvalâ is used uninitialized in this
function
Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]>
--- linux/kernel/itimer.c 2005-02-23 12:16:36.0 +0100
+++ linux-test/kernel/itimer.c 2005-02-23 21:53:10.0 +0100
@@ -58,7 +58,7 @@ int do_getitimer(int which, struct itime
if (cputime_le(cval, utime)) { /* about to fire */
val = jiffies_to_cputime(1);
} else {
- val = cputime_sub(val, utime);
+ val = cputime_sub(cval, utime);
}
}
spin_unlock_irq(&tsk->sighand->siglock);
@@ -84,7 +84,7 @@ int do_getitimer(int which, struct itime
if (cputime_le(cval, ptime)) { /* about to fire */
val = jiffies_to_cputime(1);
} else {
- val = cputime_sub(val, ptime);
+ val = cputime_sub(cval, ptime);
}
}
spin_unlock_irq(&tsk->sighand->siglock);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.11-rc4-mm1 (VFS: Cannot open root device "301")
Steven Cole <[EMAIL PROTECTED]> wrote: > > Andrew Morton wrote: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ > > > > > > - Various fixes and updates all over the place. Things seem to have slowed > > down a bit. > > > > I am having trouble getting recent -mm kernels to boot on my test box. > For 2.6.11-rc3-mm2 and 2.6.11-rc4-mm1 I get the following: > > VFS: Cannot open root device "301" or unknown-block(3,1) > Please append a correct "root=" boot option > Kernel panic - not syncing: VFS: Unable to mount root fs on > unknown-block(3,1) > > 2.6.11-rc2-mm1 boots fine, and so do plain -rc3 and -rc4. > > I copied a working .config from an earlier kernel(-rc3), and ran make > oldconfig, > answering most of the new questions 'n'. > > I did try appending root=0301 (which worked last year after similar symptoms, > but that didn't help this time). > > The root fs is ext3, which is compiled in. > ... > CONFIG_BASE_SMALL=1 Please set CONFIG_BASE_FULL=y. Check that this causes CONFIG_BASE_SMALL=0, then retest. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
Helge Hafting <[EMAIL PROTECTED]> wrote: > > This kernel came up, but my boot script complained about no /dev/hdb3 > when trying to mount /var. > (I have two IDE disks on the same cable, and an IDE cdrom on another.) > They are usually hda, hdb, and hdc. > > MAKEDEV hdq did not help. Looking at sysfs, it turns out that > /dev/hdq1 is at major:3 minor:1025 if I interpret things right. > (/dev/hda1 is at 3:1, which is correct.) > These numbers did not work with my mknod, it created 7:1 instead. > So I didn't get to test this mysterious device. > > But I assume this is a mistake of some sort, I haven't heard about any > change in the IDE numbering coming up? 2.6.1-rc3-mm1 works as expected. > > It may be interesting to note that my root raid-1 came up fine, > consisting of hdq1 and hda1 instead of the usual hdb1 and hda1. I don't know what could be causing that. Please send .config. If you set CONFIG_BASE_FULL=n, try setting it to `y'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1
I'm getting several modules with undefined symbols : Kernel: arch/i386/boot/bzImage is ready Building modules, stage 2. MODPOST *** Warning: "match_octal" [fs/udf/udf.ko] undefined! *** Warning: "match_token" [fs/udf/udf.ko] undefined! *** Warning: "match_int" [fs/udf/udf.ko] undefined! *** Warning: "match_strdup" [fs/isofs/isofs.ko] undefined! *** Warning: "match_token" [fs/isofs/isofs.ko] undefined! *** Warning: "match_int" [fs/isofs/isofs.ko] undefined! *** Warning: "match_octal" [fs/fuse/fuse.ko] undefined! *** Warning: "match_token" [fs/fuse/fuse.ko] undefined! *** Warning: "match_int" [fs/fuse/fuse.ko] undefined! *** Warning: "match_octal" [fs/fat/fat.ko] undefined! *** Warning: "match_strdup" [fs/fat/fat.ko] undefined! *** Warning: "match_token" [fs/fat/fat.ko] undefined! *** Warning: "match_int" [fs/fat/fat.ko] undefined! *** Warning: "match_token" [fs/ext3/ext3.ko] undefined! *** Warning: "match_int" [fs/ext3/ext3.ko] undefined! *** Warning: "match_token" [fs/ext2/ext2.ko] undefined! *** Warning: "match_int" [fs/ext2/ext2.ko] undefined! *** Warning: "match_octal" [drivers/usb/core/usbcore.ko] undefined! *** Warning: "match_token" [drivers/usb/core/usbcore.ko] undefined! *** Warning: "match_int" [drivers/usb/core/usbcore.ko] undefined! my .config is attached Regards, Vincent config-2.6.11-rc4-mm1 Description: Binary data
Re: 2.6.11-rc4-mm1 (VFS: Cannot open root device "301")
Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ - Various fixes and updates all over the place. Things seem to have slowed down a bit. I am having trouble getting recent -mm kernels to boot on my test box. For 2.6.11-rc3-mm2 and 2.6.11-rc4-mm1 I get the following: VFS: Cannot open root device "301" or unknown-block(3,1) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,1) 2.6.11-rc2-mm1 boots fine, and so do plain -rc3 and -rc4. I copied a working .config from an earlier kernel(-rc3), and ran make oldconfig, answering most of the new questions 'n'. I did try appending root=0301 (which worked last year after similar symptoms, but that didn't help this time). The root fs is ext3, which is compiled in. Any help appreciated. Steven Output of grep ^CONFIG .config: CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCALVERSION="-GX110" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_BASE_SMALL=1 CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_X86_PC=y CONFIG_MPENTIUMIII=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_EDD=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_PHYSICAL_START=0x10 CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_LEGACY_PROC=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=32000 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=y CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_PIIX=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_XFRM=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_MII=y CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=y CONFIG_INPUT=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y CONFIG_SERIO_LIBPS2=y CONFIG_SOUND_GAMEPORT=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_FTAPE=y CONFIG_ZFTAPE=y CONFIG_ZFT_DFLT_BLK_SZ=10240 CONFIG_ZFT_COMPRESSOR=y CONFIG_FT_NR_BUFFERS=3 CONFIG_FT_PROC_FS=y CONFIG_FT_NORMAL_DEBUG=y CONFIG_FT_STD_FDC=y CONFIG_FT_FDC_THR=8 CONFIG_FT_FDC_MAX_RATE=2000 CONFIG_FT_ALPHA_CLOCK=0 CONFIG_AGP=y CONFIG_AGP_INTEL=y CONFIG_VIDEO_DEV=y CONFIG_VIDEO_SELECT=y CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT3_FS=y CONFIG_JBD=y CONFIG_FS_MBCACHE=y CONFIG_REISER4_FS=y CONFIG_REISERFS_FS=y CONFIG_ISO9660_FS=y CONFIG_FAT_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=y CONFIG_NTFS_RW=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y CONFIG_DEVFS_FS=y CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_PARTITION_ADVANCED=y CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_FRAME_POINTER=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_CAPABILITIES=y CONFIG_CRC_CCITT=y CONFIG_CRC32=y CONFIG_LIBCRC32C=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org
Re: 2.6.11-rc4-mm1
On Wed, 2005-02-23 at 12:03 +0100, Mathieu Segaud wrote: > it is the latest Robert Love posted against -mm kernels, but in > inotify_ignore(): I posted an updated patch last Friday, which fixed this. Anyhow, this is the correct fix. Signed-off-by: Robert Love <[EMAIL PROTECTED]> Thanks, Robert Love - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
This kernel came up, but my boot script complained about no /dev/hdb3 when trying to mount /var. (I have two IDE disks on the same cable, and an IDE cdrom on another.) They are usually hda, hdb, and hdc. MAKEDEV hdq did not help. Looking at sysfs, it turns out that /dev/hdq1 is at major:3 minor:1025 if I interpret things right. (/dev/hda1 is at 3:1, which is correct.) These numbers did not work with my mknod, it created 7:1 instead. So I didn't get to test this mysterious device. But I assume this is a mistake of some sort, I haven't heard about any change in the IDE numbering coming up? 2.6.1-rc3-mm1 works as expected. It may be interesting to note that my root raid-1 came up fine, consisting of hdq1 and hda1 instead of the usual hdb1 and hda1. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1
> - Last, final, ultimate call: if anyone has patches in here which are 2.6.11 > material, please tell me. I guess that depends on how you define 2.6.11 material at this point, but I have a few patches that I wrote in there, that I think are potential candidates due to them being fairly trivial, obviously correct and not having caused any problems since entering -mm. Those patches might as well get merged into 2.6.11 now and get out of your queue/hair. The patches I have in mind are these: fix-placement-of-static-inline-in-nfsdh.patch -- This one has no actual impact on the generated code, it just kills a few warnings when building with gcc -W, so merging that up should be harmless. kyrofb-copy__user-return-value-checks-added-to-kyro-fb.patch -- This one just adds a few return value checks to copy_*_user calls and returns -EFAULT when failing. I've seen no complains about the patch on the list and it seems to be the obviously correct thing to do - might as well get merged. warning-fix-in-drivers-cdrom-mcdc.patch -- Trivial, obviously correct, warning fix to an ancient driver. No point in having you carry it around in -mm, let's just merge it. make-loglevels-in-init-mainc-a-little-more-sane.patch -- This one just changes a few loglevels, so the potential for breakage is extremely low. Besides I believe I've argued the case for the new loglevels being more sane than the old ones well enough, and noone has complained about the patch. The patches above are all very low risk, so they shouldn't cause any problems for 2.6.11. Let us merge them now to a) get the bennefit of them in 2.6.11 and b) get them out of your -mm queue. nitpick note: despite some of these patches having From: lines in them in your -mm patch set that list other people they where all written by me. Other people getting listed as From: (and thus later as patch author in the changelogs and bk) seems to happen when other people resend the patches to the list or when they pass through maintainers before they reach you. Just to set the record straight; I initially wrote the patches above. Kind regards, Jesper Juhl <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1
Andrew Morton <[EMAIL PROTECTED]> disait derniÃrement que :
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/
>
>
> - Various fixes and updates all over the place. Things seem to have slowed
> down a bit.
>
> - Last, final, ultimate call: if anyone has patches in here which are 2.6.11
> material, please tell me.
>
>
>
> Changes since 2.6.11-rc3-mm1:
[snip]
> +inotify.patch
>
> Not sure if this is the latest version.
it is the latest Robert Love posted against -mm kernels, but in
inotify_ignore():
static int inotify_ignore(struct inotify_device *dev, s32 wd)
{
struct inotify_watch *watch;
int ret = 0;
spin_lock(&dev->lock);
watch = dev_find_wd(dev, wd);
spin_unlock(&dev->lock); <- lock is released, but
if (!watch) {
ret = -EINVAL;
goto out;
}
__remove_watch(watch, dev); <-- must be called with lock held
out:
spin_unlock(&dev->lock); <- anyway, lock is
return ret; released and sub_preempt_count
} BUG's on SMP and PREEMPT
__remove_watch() must be called with ->lock held on dev.
Anyway, ->lock is released after label out.
Signed-off-by: Mathieu Segaud <[EMAIL PROTECTED]>
--- a/drivers/char/inotify.c 2005-02-23 11:55:21.321385752 +0100
+++ b/drivers/char/inotify.c 2005-02-23 11:55:29.772101048 +0100
@@ -952,7 +952,7 @@
spin_lock(&dev->lock);
watch = dev_find_wd(dev, wd);
- spin_unlock(&dev->lock);
+
if (!watch) {
ret = -EINVAL;
goto out;
--
> Can you explain this behaviour?
Yes
--
Alan
[Oh wait you want to know why...]
- Alan Cox on linux-kernel
