[OT] GMail (was USB regression (and other failures)...)
On Sat, Feb 16, 2008 at 08:12:40PM -0500, Andrew Buehler wrote: > [...] and I would not be in the least surprised if this turned out to > be yet one more problem with gmail It is; Gmail will refuse to POP more than one copy of a mail to you, no matter how many copies it recieves via different paths. Which copy you get seems to be dependant on which arrives first, so you can't even hope a mail exchange will consistently arrive in one mailbox or another. Note that this also applies to mails cross-posted to multiple lists you maybe be suscribed to; this breaks threading fantastically. Google is aware of the issue, and considers it a feature. If you find another free mail service which isn't so broken, I'd love to hear about it. --- That said, netiquette on the kernel lists is to *never* drop CC's. Too much traffic crosses the lists for anyone to read it all and note anything they might be interested and/or implicated in. Never dropping CC's allows busy people to keep track of conversations they've taken part in or that someone thinks they should see without the worry of missing any important parts of one. Or at least it does if your mail system isn't broken. We get what we pay for. :-/ -- Joseph Fannin [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/
[OT] GMail (was USB regression (and other failures)...)
On Sat, Feb 16, 2008 at 08:12:40PM -0500, Andrew Buehler wrote: [...] and I would not be in the least surprised if this turned out to be yet one more problem with gmail It is; Gmail will refuse to POP more than one copy of a mail to you, no matter how many copies it recieves via different paths. Which copy you get seems to be dependant on which arrives first, so you can't even hope a mail exchange will consistently arrive in one mailbox or another. Note that this also applies to mails cross-posted to multiple lists you maybe be suscribed to; this breaks threading fantastically. Google is aware of the issue, and considers it a feature. If you find another free mail service which isn't so broken, I'd love to hear about it. --- That said, netiquette on the kernel lists is to *never* drop CC's. Too much traffic crosses the lists for anyone to read it all and note anything they might be interested and/or implicated in. Never dropping CC's allows busy people to keep track of conversations they've taken part in or that someone thinks they should see without the worry of missing any important parts of one. Or at least it does if your mail system isn't broken. We get what we pay for. :-/ -- Joseph Fannin [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: [RFT 1/1] single_chip test
On Wed, Feb 06, 2008 at 11:42:40AM +0100, Jiri Slaby wrote: > On 02/05/2008 11:57 PM, Tino Keitel wrote: > > Hi, > > > > I tried the current git (9ef9dc69d4167276c04590d67ee55de8380bc1ad) and > > got the following error message from ath5k: > > > > ath5k_pci :02:00.0: registered as 'phy0' > > ath5k phy0: failed to resume the MAC Chip > > ath5k_pci: probe of :02:00.0 failed with error -5 > > We failed to resume after a hardware reset here for a whole second. Is there > any > version of ath5k which worked for you (is this a regression)? I cannot speak for Tino, but my ath5k never worked in MacBook -- it failed the same way, and I believe the hardware was the same. My understanding was that it was a known bug with PCIE devices, but I got that out of reading list archives. > > > Here is the lspci -vnn output: > > > > 02:00.0 Ethernet controller [0200]: Atheros Communications, Inc. > > AR5006EG 802.11 b/g Wireless PCI Express Adapter [168c:001c] (rev 01) > > Subsystem: Apple Computer Inc. Unknown device [106b:0086] > > Flags: fast devsel, IRQ 17 > > Memory at 9010 (64-bit, non-prefetchable) [disabled] > > [size=64K] > > Capabilities: [40] Power Management version 2 > > Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- > > Queue=0/0 Enable- > > Capabilities: [60] Express Legacy Endpoint, MSI 00 > > Capabilities: [90] MSI-X: Enable- Mask- TabSize=1 > > Capabilities: [100] Advanced Error Reporting > > Capabilities: [140] Virtual Channel > > Kernel modules: ath5k > > > > The same device works with madwifi: > > > > ath_rate_sample: 1.2 (svn r3339) > > MadWifi: ath_attach: Switching per-packet transmit power control off > > wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > > wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > > wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps > > 24Mbps 36Mbps 48Mbps 54Mbps > > wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > > wifi0: H/W encryption support: WEP AES AES_CCM TKIP > > wifi0: ath_announce: Use hw queue 1 for WME_AC_BE traffic > > wifi0: ath_announce: Use hw queue 0 for WME_AC_BK traffic > > wifi0: ath_announce: Use hw queue 2 for WME_AC_VI traffic > > wifi0: ath_announce: Use hw queue 3 for WME_AC_VO traffic > > wifi0: ath_announce: Use hw queue 8 for CAB traffic > > wifi0: ath_announce: Use hw queue 9 for beacons > > ath_pci: wifi0: Atheros 5424/2424: mem=0x9010, irq=17 > > > > I can also set the interface up and use iwlist ath0 scan. > > Hmm, I guess madwif-old-openhal doesn't work either. > > I suspect ath5k_hw_nic_wakeup being called before setting ah_single_chip in > ath5k_hw_attach. Could you test the attached patch? I cannot, as my MacBook is now broken. -- Joseph Fannin [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: [RFT 1/1] single_chip test
On Wed, Feb 06, 2008 at 11:42:40AM +0100, Jiri Slaby wrote: On 02/05/2008 11:57 PM, Tino Keitel wrote: Hi, I tried the current git (9ef9dc69d4167276c04590d67ee55de8380bc1ad) and got the following error message from ath5k: ath5k_pci :02:00.0: registered as 'phy0' ath5k phy0: failed to resume the MAC Chip ath5k_pci: probe of :02:00.0 failed with error -5 We failed to resume after a hardware reset here for a whole second. Is there any version of ath5k which worked for you (is this a regression)? I cannot speak for Tino, but my ath5k never worked in MacBook -- it failed the same way, and I believe the hardware was the same. My understanding was that it was a known bug with PCIE devices, but I got that out of reading list archives. Here is the lspci -vnn output: 02:00.0 Ethernet controller [0200]: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter [168c:001c] (rev 01) Subsystem: Apple Computer Inc. Unknown device [106b:0086] Flags: fast devsel, IRQ 17 Memory at 9010 (64-bit, non-prefetchable) [disabled] [size=64K] Capabilities: [40] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [60] Express Legacy Endpoint, MSI 00 Capabilities: [90] MSI-X: Enable- Mask- TabSize=1 Capabilities: [100] Advanced Error Reporting ? Capabilities: [140] Virtual Channel ? Kernel modules: ath5k The same device works with madwifi: ath_rate_sample: 1.2 (svn r3339) MadWifi: ath_attach: Switching per-packet transmit power control off wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: H/W encryption support: WEP AES AES_CCM TKIP wifi0: ath_announce: Use hw queue 1 for WME_AC_BE traffic wifi0: ath_announce: Use hw queue 0 for WME_AC_BK traffic wifi0: ath_announce: Use hw queue 2 for WME_AC_VI traffic wifi0: ath_announce: Use hw queue 3 for WME_AC_VO traffic wifi0: ath_announce: Use hw queue 8 for CAB traffic wifi0: ath_announce: Use hw queue 9 for beacons ath_pci: wifi0: Atheros 5424/2424: mem=0x9010, irq=17 I can also set the interface up and use iwlist ath0 scan. Hmm, I guess madwif-old-openhal doesn't work either. I suspect ath5k_hw_nic_wakeup being called before setting ah_single_chip in ath5k_hw_attach. Could you test the attached patch? I cannot, as my MacBook is now broken. -- Joseph Fannin [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.24-rc8-mm1 - mkubootimg wants
On Thu, Jan 17, 2008 at 02:35:14AM -0800, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/ > git-kbuild.patch The "kbuild: rework arch specific Makefiles to use mkubootimg" changeset in Kbuild git introduces a kernel build dependency on the system zlib.h headers; scripts/mkubootimg/crc32.c wants it. The build errors out if those headers aren't installed. Was this intentional? -- Joseph Fannin [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.24-rc8-mm1 - mkubootimg wants zlib.h
On Thu, Jan 17, 2008 at 02:35:14AM -0800, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/ git-kbuild.patch The kbuild: rework arch specific Makefiles to use mkubootimg changeset in Kbuild git introduces a kernel build dependency on the system zlib.h headers; scripts/mkubootimg/crc32.c wants it. The build errors out if those headers aren't installed. Was this intentional? -- Joseph Fannin [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.24-rc6-mm1: __raw_spin_is_contended undefined
On Sat, Dec 22, 2007 at 11:30:56PM -0800, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/ > This doesn't build on powerpc with my .config: In file included from arch/powerpc/kernel/asm-offsets.c:17: include/linux/sched.h: In function ‘spin_needbreak’: include/linux/sched.h:1947: error: implicit declaration of function ‘__raw_spin_is_contended’ I don't see where __raw_spin_is_contended is defined for any arch other than x86, so I guess this will happen on any non-x86 arch when SMP=y and PREEMPT=y are set? This comes from "spinlock: lockbreak cleanup" in git-x86. -- Joseph Fannin [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.24-rc6-mm1: __raw_spin_is_contended undefined
On Sat, Dec 22, 2007 at 11:30:56PM -0800, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/ This doesn't build on powerpc with my .config: In file included from arch/powerpc/kernel/asm-offsets.c:17: include/linux/sched.h: In function ‘spin_needbreak’: include/linux/sched.h:1947: error: implicit declaration of function ‘__raw_spin_is_contended’ I don't see where __raw_spin_is_contended is defined for any arch other than x86, so I guess this will happen on any non-x86 arch when SMP=y and PREEMPT=y are set? This comes from spinlock: lockbreak cleanup in git-x86. -- Joseph Fannin [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: x86_64 ten times slower than i386
On Sat, Nov 03, 2007 at 11:38:24PM +0100, Bo Brantén wrote: > On Sat, 3 Nov 2007, Matt Mackall wrote: > >> This is typically due to a problem with the setup of your MTRRs. Try >> booting with mem=nnnM where nnn is some number smaller than your >> actual amount of memory. > > Thank you for that advice, the system has 4GB and if I boot with mem=3072M > it will run as fast as normal Also, check if a BIOS upgrade is available -- it's possible that a newer BIOS will have fixed this. -- Joseph Fannin [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: x86_64 ten times slower than i386
On Sat, Nov 03, 2007 at 11:38:24PM +0100, Bo Brantén wrote: On Sat, 3 Nov 2007, Matt Mackall wrote: This is typically due to a problem with the setup of your MTRRs. Try booting with mem=nnnM where nnn is some number smaller than your actual amount of memory. Thank you for that advice, the system has 4GB and if I boot with mem=3072M it will run as fast as normal Also, check if a BIOS upgrade is available -- it's possible that a newer BIOS will have fixed this. -- Joseph Fannin [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.24-rc1 fails with lockup and BUG:
On Wed, Oct 24, 2007 at 03:25:44PM +0200, Romano Giannetti wrote:
>
> Hi,
>
> 2.6.23-rc1 fails for me. I have the sensation it is network-related, but
> I am not sure, so I send this message just to the list.
> This same failure was present in git-5734-gd85714d, I sent
> a message to the list but it seems it never arrived. I hope this will
> pass through. My system is a toshiba satellite A305-S5077, dual core pentium.
>
> The symptoms are quite strange. At boot, NetworkManager fails to activate
> my eth0 (r8169). Just stopping/restarting NM will make it works.
Denis V. Lunev wrote a patch for the NetworkManager thing a day or two
ago (which DaveM has queued).
Since netlink is involved in the traces you sent, this might do something
for the other too.
The patch I recieved follows:
> Revert to original netlink behavior. Do not reply with ACK if the
> netlink dump has bees successfully started.
> libnl has been broken by the cd40b7d3983c708aabe3d3008ec64ffce56d33b0
> The following command reproduce the problem:
>/nl-route-get 192.168.1.1
> Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 98e313e..44a8b41 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1565,7 +1565,10 @@ int netlink_dump_start(struct sock *ssk, struct sk_buff
*skb,
netlink_dump(sk);
sock_put(sk);
- return 0;
+
+ /* We successfully started a dump, by returning -EINTR we
+* signal not to send ACK even if it was requested */
+ return -EINTR;
}
void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err)
@@ -1619,17 +1622,21 @@ int netlink_rcv_skb(struct sk_buff *skb, int
(*cb)(struct sk_buff *,
/* Only requests are handled by the kernel */
if (!(nlh->nlmsg_flags & NLM_F_REQUEST))
- goto skip;
+ goto ack;
/* Skip control messages */
if (nlh->nlmsg_type < NLMSG_MIN_TYPE)
- goto skip;
+ goto ack;
err = cb(skb, nlh);
-skip:
+ if (err == -EINTR)
+ goto skip;
+
+ack:
if (nlh->nlmsg_flags & NLM_F_ACK || err)
netlink_ack(skb, nlh, err);
+skip:
msglen = NLMSG_ALIGN(nlh->nlmsg_len);
if (msglen > skb->len)
msglen = skb->len;
--
Joseph Fannin
[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.24-rc1 fails with lockup and BUG:
On Wed, Oct 24, 2007 at 03:25:44PM +0200, Romano Giannetti wrote: Hi, 2.6.23-rc1 fails for me. I have the sensation it is network-related, but I am not sure, so I send this message just to the list. This same failure was present in git-5734-gd85714d, I sent a message to the list but it seems it never arrived. I hope this will pass through. My system is a toshiba satellite A305-S5077, dual core pentium. The symptoms are quite strange. At boot, NetworkManager fails to activate my eth0 (r8169). Just stopping/restarting NM will make it works. Denis V. Lunev wrote a patch for the NetworkManager thing a day or two ago (which DaveM has queued). Since netlink is involved in the traces you sent, this might do something for the other too. The patch I recieved follows: Revert to original netlink behavior. Do not reply with ACK if the netlink dump has bees successfully started. libnl has been broken by the cd40b7d3983c708aabe3d3008ec64ffce56d33b0 The following command reproduce the problem: /nl-route-get 192.168.1.1 Signed-off-by: Denis V. Lunev [EMAIL PROTECTED] diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c index 98e313e..44a8b41 100644 --- a/net/netlink/af_netlink.c +++ b/net/netlink/af_netlink.c @@ -1565,7 +1565,10 @@ int netlink_dump_start(struct sock *ssk, struct sk_buff *skb, netlink_dump(sk); sock_put(sk); - return 0; + + /* We successfully started a dump, by returning -EINTR we +* signal not to send ACK even if it was requested */ + return -EINTR; } void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err) @@ -1619,17 +1622,21 @@ int netlink_rcv_skb(struct sk_buff *skb, int (*cb)(struct sk_buff *, /* Only requests are handled by the kernel */ if (!(nlh-nlmsg_flags NLM_F_REQUEST)) - goto skip; + goto ack; /* Skip control messages */ if (nlh-nlmsg_type NLMSG_MIN_TYPE) - goto skip; + goto ack; err = cb(skb, nlh); -skip: + if (err == -EINTR) + goto skip; + +ack: if (nlh-nlmsg_flags NLM_F_ACK || err) netlink_ack(skb, nlh, err); +skip: msglen = NLMSG_ALIGN(nlh-nlmsg_len); if (msglen skb-len) msglen = skb-len; -- Joseph Fannin [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.23-mm1 pm_prepare() and _finish() w/ args vs. without
On Mon, Oct 15, 2007 at 10:55:06PM +0200, Rafael J. Wysocki wrote: > On Sunday, 14 October 2007 22:20, Rafael J. Wysocki wrote: > > On Sunday, 14 October 2007 21:47, Joseph Fannin wrote: > > > On Sat, Oct 13, 2007 at 09:13:13PM +0200, Rafael J. Wysocki wrote: > > > > > > > Yes. Corrected patch follows. > > > > > > A bit more is needed due to the rename of lite5200_pm_init() to > > > lite5200_suspend_init(). > > > > Well, I didn't intend to change it. :-) > > > > > An amended patch follows that builds and boots on my powermac. > > > > Thanks. > > > > Can you please try the alternative one below? > > > > I just removed the renaming of lite5200_pm_init() from it. > > Well, from the lack of response I gather it works. :-) > > I'm going to send it in a separate thread with a changelog. Please object if > it doesn't work. This patch builds and boots on my powermac. Also, I checked, and the remaning warnings from gcc in this general area are also present in Linus's -git. > Greetings, > Rafael Thanks! -- Joseph Fannin [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.23-mm1 pm_prepare() and _finish() w/ args vs. without
On Mon, Oct 15, 2007 at 10:55:06PM +0200, Rafael J. Wysocki wrote: On Sunday, 14 October 2007 22:20, Rafael J. Wysocki wrote: On Sunday, 14 October 2007 21:47, Joseph Fannin wrote: On Sat, Oct 13, 2007 at 09:13:13PM +0200, Rafael J. Wysocki wrote: Yes. Corrected patch follows. A bit more is needed due to the rename of lite5200_pm_init() to lite5200_suspend_init(). Well, I didn't intend to change it. :-) An amended patch follows that builds and boots on my powermac. Thanks. Can you please try the alternative one below? I just removed the renaming of lite5200_pm_init() from it. Well, from the lack of response I gather it works. :-) I'm going to send it in a separate thread with a changelog. Please object if it doesn't work. This patch builds and boots on my powermac. Also, I checked, and the remaning warnings from gcc in this general area are also present in Linus's -git. Greetings, Rafael Thanks! -- Joseph Fannin [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.23-mm1 pm_prepare() and _finish() w/ args vs. without
ar saved_sram[0x4000]; /* reuse buffer from mpc52xx suspend */ #endif #endif /* CONFIG_PM */ -- Joseph Fannin [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.23-mm1 pm_prepare() and _finish() w/ args vs. without
int mpc52xx_pm_finish(suspend_state_t); +extern void mpc52xx_pm_finish(void); extern char saved_sram[0x4000]; /* reuse buffer from mpc52xx suspend */ #endif #endif /* CONFIG_PM */ -- Joseph Fannin [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.23-mm1 pm_prepare() and _finish() w/ args vs. without
On Sat, Oct 13, 2007 at 07:22:48PM +0200, Rafael J. Wysocki wrote: > On Saturday, 13 October 2007 17:50, Joseph Fannin wrote: > > On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > > > > > Domen Puncer's change to support "MPC5200 low power mode" (in > > powerpc-git, which is in Linus's tree now) adds new code calling > > mpc52xx_pm_prepare and _finish with suspend_state_t as an argument, > > while Rafael Wysocki's pm-rework-struct-platform_suspend_ops.patch > > converts those to take no arguments. So the build fails: > > Ouch. > > I think that the appended patch is needed. Unfortunately, I can't test it > here. > > --- linux-2.6.23-mm1.orig/include/asm-powerpc/mpc52xx.h > +++ linux-2.6.23-mm1/include/asm-powerpc/mpc52xx.h > @@ -267,9 +267,9 @@ extern int mpc52xx_set_wakeup_gpio(u8 pi > extern int __init lite5200_pm_init(void); > > /* lite5200 calls mpc5200 suspend functions, so here they are */ > -extern int mpc52xx_pm_prepare(suspend_state_t); > +extern int mpc52xx_pm_prepare(void); > extern int mpc52xx_pm_enter(suspend_state_t); > -extern int mpc52xx_pm_finish(suspend_state_t); > +extern void mpc52xx_pm_finish(void); These declarations are extern, but pm-rework-struct-platform_suspend_ops.patch makes the function definitions static, which doesn't seem to be allowed. After removing the static bits from those two functions in mpc52xx_pm.c it builds, but there are lots of warnings, which seem to be related: CC arch/powerpc/kernel/prom.o In file included from arch/powerpc/platforms/52xx/mpc52xx_pic.c:34: include/asm/mpc52xx.h:271: warning: parameter names (without types) in function declaration CC arch/powerpc/platforms/52xx/mpc52xx_common.o arch/powerpc/kernel/prom.c: In function ‘early_init_dt_scan_chosen’: arch/powerpc/kernel/prom.c:784: warning: assignment from incompatible pointer type arch/powerpc/kernel/prom.c:788: warning: assignment from incompatible pointer type In file included from arch/powerpc/platforms/52xx/mpc52xx_common.c:20: include/asm/mpc52xx.h:271: warning: parameter names (without types) in function declaration CC arch/powerpc/platforms/52xx/mpc52xx_pci.o CC arch/powerpc/kernel/traps.o In file included from arch/powerpc/platforms/52xx/mpc52xx_pci.c:16: include/asm/mpc52xx.h:271: warning: parameter names (without types) in function declaration arch/powerpc/platforms/52xx/mpc52xx_pci.c: In function ‘mpc52xx_pci_setup’: arch/powerpc/platforms/52xx/mpc52xx_pci.c:262: warning: format ‘%x’ expects type ‘unsigned int’, but argument 2 has type ‘resource_size_t’ arch/powerpc/platforms/52xx/mpc52xx_pci.c:262: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘resource_size_t’ arch/powerpc/platforms/52xx/mpc52xx_pci.c:276: warning: format ‘%x’ expects type ‘unsigned int’, but argument 2 has type ‘resource_size_t’ arch/powerpc/platforms/52xx/mpc52xx_pci.c:276: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘resource_size_t’ arch/powerpc/platforms/52xx/mpc52xx_pci.c:295: warning: cast to pointer from integer of different size arch/powerpc/platforms/52xx/mpc52xx_pci.c:295: warning: format ‘%x’ expects type ‘unsigned int’, but argument 2 has type ‘resource_size_t’ arch/powerpc/platforms/52xx/mpc52xx_pci.c:295: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘resource_size_t’ CC arch/powerpc/platforms/52xx/efika.o In file included from arch/powerpc/platforms/52xx/efika.c:36: include/asm/mpc52xx.h:271: warning: parameter names (without types) in function declaration CC arch/powerpc/kernel/setup-common.o CC arch/powerpc/platforms/52xx/lite5200.o In file included from arch/powerpc/platforms/52xx/lite5200.c:44: include/asm/mpc52xx.h:271: warning: parameter names (without types) in function declaration The build is moving though, and I don't actually have this platform -- I just can't avoid building it when building for powermac. Thanks. -- Joseph Fannin [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.23-mm1 pm_prepare() and _finish() w/ args vs. without
On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
Domen Puncer's change to support "MPC5200 low power mode" (in
powerpc-git, which is in Linus's tree now) adds new code calling
mpc52xx_pm_prepare and _finish with suspend_state_t as an argument,
while Rafael Wysocki's pm-rework-struct-platform_suspend_ops.patch
converts those to take no arguments. So the build fails:
arch/powerpc/platforms/52xx/mpc52xx_pm.c:61: error: conflicting types
for ‘mpc52xx_pm_prepare’
include/asm/mpc52xx.h:270: error: previous declaration of
‘mpc52xx_pm_prepare’ was here
arch/powerpc/platforms/52xx/mpc52xx_pm.c:167: error: conflicting types
for ‘mpc52xx_pm_finish’
include/asm/mpc52xx.h:272: error: previous declaration of
‘mpc52xx_pm_finish’ was here
Sorting this out is beyond my abilities; I don't know how to deal with
stuff like this (in arch/powerpc/platforms/52xx/lite5200_pm.c):
static int lite5200_pm_prepare(suspend_state_t state)
{
/* deep sleep? let mpc52xx code handle that */
if (state == PM_SUSPEND_STANDBY)
return mpc52xx_pm_prepare(state);
Patch authors CC'd.
--
Joseph Fannin
[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.23-mm1 pm_prepare() and _finish() w/ args vs. without
On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
Domen Puncer's change to support MPC5200 low power mode (in
powerpc-git, which is in Linus's tree now) adds new code calling
mpc52xx_pm_prepare and _finish with suspend_state_t as an argument,
while Rafael Wysocki's pm-rework-struct-platform_suspend_ops.patch
converts those to take no arguments. So the build fails:
arch/powerpc/platforms/52xx/mpc52xx_pm.c:61: error: conflicting types
for ‘mpc52xx_pm_prepare’
include/asm/mpc52xx.h:270: error: previous declaration of
‘mpc52xx_pm_prepare’ was here
arch/powerpc/platforms/52xx/mpc52xx_pm.c:167: error: conflicting types
for ‘mpc52xx_pm_finish’
include/asm/mpc52xx.h:272: error: previous declaration of
‘mpc52xx_pm_finish’ was here
Sorting this out is beyond my abilities; I don't know how to deal with
stuff like this (in arch/powerpc/platforms/52xx/lite5200_pm.c):
static int lite5200_pm_prepare(suspend_state_t state)
{
/* deep sleep? let mpc52xx code handle that */
if (state == PM_SUSPEND_STANDBY)
return mpc52xx_pm_prepare(state);
Patch authors CC'd.
--
Joseph Fannin
[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.23-mm1 pm_prepare() and _finish() w/ args vs. without
On Sat, Oct 13, 2007 at 07:22:48PM +0200, Rafael J. Wysocki wrote: On Saturday, 13 October 2007 17:50, Joseph Fannin wrote: On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ Domen Puncer's change to support MPC5200 low power mode (in powerpc-git, which is in Linus's tree now) adds new code calling mpc52xx_pm_prepare and _finish with suspend_state_t as an argument, while Rafael Wysocki's pm-rework-struct-platform_suspend_ops.patch converts those to take no arguments. So the build fails: Ouch. I think that the appended patch is needed. Unfortunately, I can't test it here. --- linux-2.6.23-mm1.orig/include/asm-powerpc/mpc52xx.h +++ linux-2.6.23-mm1/include/asm-powerpc/mpc52xx.h @@ -267,9 +267,9 @@ extern int mpc52xx_set_wakeup_gpio(u8 pi extern int __init lite5200_pm_init(void); /* lite5200 calls mpc5200 suspend functions, so here they are */ -extern int mpc52xx_pm_prepare(suspend_state_t); +extern int mpc52xx_pm_prepare(void); extern int mpc52xx_pm_enter(suspend_state_t); -extern int mpc52xx_pm_finish(suspend_state_t); +extern void mpc52xx_pm_finish(void); These declarations are extern, but pm-rework-struct-platform_suspend_ops.patch makes the function definitions static, which doesn't seem to be allowed. After removing the static bits from those two functions in mpc52xx_pm.c it builds, but there are lots of warnings, which seem to be related: CC arch/powerpc/kernel/prom.o In file included from arch/powerpc/platforms/52xx/mpc52xx_pic.c:34: include/asm/mpc52xx.h:271: warning: parameter names (without types) in function declaration CC arch/powerpc/platforms/52xx/mpc52xx_common.o arch/powerpc/kernel/prom.c: In function ‘early_init_dt_scan_chosen’: arch/powerpc/kernel/prom.c:784: warning: assignment from incompatible pointer type arch/powerpc/kernel/prom.c:788: warning: assignment from incompatible pointer type In file included from arch/powerpc/platforms/52xx/mpc52xx_common.c:20: include/asm/mpc52xx.h:271: warning: parameter names (without types) in function declaration CC arch/powerpc/platforms/52xx/mpc52xx_pci.o CC arch/powerpc/kernel/traps.o In file included from arch/powerpc/platforms/52xx/mpc52xx_pci.c:16: include/asm/mpc52xx.h:271: warning: parameter names (without types) in function declaration arch/powerpc/platforms/52xx/mpc52xx_pci.c: In function ‘mpc52xx_pci_setup’: arch/powerpc/platforms/52xx/mpc52xx_pci.c:262: warning: format ‘%x’ expects type ‘unsigned int’, but argument 2 has type ‘resource_size_t’ arch/powerpc/platforms/52xx/mpc52xx_pci.c:262: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘resource_size_t’ arch/powerpc/platforms/52xx/mpc52xx_pci.c:276: warning: format ‘%x’ expects type ‘unsigned int’, but argument 2 has type ‘resource_size_t’ arch/powerpc/platforms/52xx/mpc52xx_pci.c:276: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘resource_size_t’ arch/powerpc/platforms/52xx/mpc52xx_pci.c:295: warning: cast to pointer from integer of different size arch/powerpc/platforms/52xx/mpc52xx_pci.c:295: warning: format ‘%x’ expects type ‘unsigned int’, but argument 2 has type ‘resource_size_t’ arch/powerpc/platforms/52xx/mpc52xx_pci.c:295: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘resource_size_t’ CC arch/powerpc/platforms/52xx/efika.o In file included from arch/powerpc/platforms/52xx/efika.c:36: include/asm/mpc52xx.h:271: warning: parameter names (without types) in function declaration CC arch/powerpc/kernel/setup-common.o CC arch/powerpc/platforms/52xx/lite5200.o In file included from arch/powerpc/platforms/52xx/lite5200.c:44: include/asm/mpc52xx.h:271: warning: parameter names (without types) in function declaration The build is moving though, and I don't actually have this platform -- I just can't avoid building it when building for powermac. Thanks. -- Joseph Fannin [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: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
FWIW, on all the hardware I have, Windows is able to deal with: (1) hibernate Windows (2) run $(OTHER_OS) (3) resume Windows ... which seems to me to say that Linux is doing it wrong if it can't handle other ACPI users between hibernate and resume. But maybe that's just my hardware. -- Joseph Fannin [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: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Fri, Sep 21, 2007 at 11:45:12AM +0200, Pavel Machek wrote: > Hi! > > > > > > Sounds doable, as long as you can cope with long command lines (which > > > shouldn't be a biggie). (If you've got a swapfile or parts of a swap > > > partition already in use, it can be quite fragmented). > > > > Hmm. This is an interesting problem. Sharing a swap file or a swap > > partition with the actual swap of user space pages does seem to be > > a limitation of this approach. > > > > Although the fact that it is simple to write to a separate file may > > be a reasonable compensation. > > I'm not sure how you'd write it to a separate file. Notice that kjump > kernel may not mount journalling filesystems, not even > read-only. (Ext3 replays journal in that case). You could pass block > numbers from the original kernel... The ext3 thing is a bug, the case for which I don't think has been adequately explained to the ext[34] folks. There should be at least a no_replay mount flag available, or something. It has ramifications for more than just hibernation. And yeah, I'm gonna bring up the swap files thing again. If you can hibernate to a swap file, you can hibernate to a dedicated hibernation file, and vice versa. If you can't hibernate to a swap file, then swap files are effectively unsupported for any system you might want to hibernate. I wonder what embedded folks would think about that . But, in my ignorance, I'm not sure even fixing the ext3 bug will guarantee you consistent metadata so that you can handle a swap/hibernate file. You can do a sync(), but how do you make that not race against running processes without the freezer, or blkdev snapshots? I guess uswsusp and the-patch-previously-known-as-suspend2 handle this somehow, though. (It's that same ignorance that has me waiting for someone with established credit with kernel people to make that argument for the ext3 bug, so I can hang my own reasons for thinking that it's bad off of theirs). -- Joseph Fannin [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: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Fri, Sep 21, 2007 at 11:45:12AM +0200, Pavel Machek wrote: Hi! Sounds doable, as long as you can cope with long command lines (which shouldn't be a biggie). (If you've got a swapfile or parts of a swap partition already in use, it can be quite fragmented). Hmm. This is an interesting problem. Sharing a swap file or a swap partition with the actual swap of user space pages does seem to be a limitation of this approach. Although the fact that it is simple to write to a separate file may be a reasonable compensation. I'm not sure how you'd write it to a separate file. Notice that kjump kernel may not mount journalling filesystems, not even read-only. (Ext3 replays journal in that case). You could pass block numbers from the original kernel... The ext3 thing is a bug, the case for which I don't think has been adequately explained to the ext[34] folks. There should be at least a no_replay mount flag available, or something. It has ramifications for more than just hibernation. And yeah, I'm gonna bring up the swap files thing again. If you can hibernate to a swap file, you can hibernate to a dedicated hibernation file, and vice versa. If you can't hibernate to a swap file, then swap files are effectively unsupported for any system you might want to hibernate. handwave I wonder what embedded folks would think about that /handwave. But, in my ignorance, I'm not sure even fixing the ext3 bug will guarantee you consistent metadata so that you can handle a swap/hibernate file. You can do a sync(), but how do you make that not race against running processes without the freezer, or blkdev snapshots? I guess uswsusp and the-patch-previously-known-as-suspend2 handle this somehow, though. (It's that same ignorance that has me waiting for someone with established credit with kernel people to make that argument for the ext3 bug, so I can hang my own reasons for thinking that it's bad off of theirs). -- Joseph Fannin [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: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
FWIW, on all the hardware I have, Windows is able to deal with: (1) hibernate Windows (2) run $(OTHER_OS) (3) resume Windows ... which seems to me to say that Linux is doing it wrong if it can't handle other ACPI users between hibernate and resume. But maybe that's just my hardware. -- Joseph Fannin [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/
[PATCH] Remove broken netfilter binary sysctls from bridging code
The netfilter sysctls in the bridging code don't set strategy routines:
sysctl table check failed: /net/bridge/bridge-nf-call-arptables .3.10.1
Missing strategy
sysctl table check failed: /net/bridge/bridge-nf-call-iptables .3.10.2 Missing
strategy
sysctl table check failed: /net/bridge/bridge-nf-call-ip6tables .3.10.3
Missing strategy
sysctl table check failed: /net/bridge/bridge-nf-filter-vlan-tagged .3.10.4
Missing strategy
sysctl table check failed: /net/bridge/bridge-nf-filter-pppoe-tagged .3.10.5
Missing strategy
These binary sysctls can't work. The binary sysctl numbers of
other netfilter sysctls with this problem are being removed. These
need to go as well.
Signed-off-by: Joseph Fannin <[EMAIL PROTECTED]>
---
This *really* needs to be reviewed by someone who knows what this
is all about. I've simply extended the removal of netfilter binary
sysctl numbers so I could load bridge.ko. I don't particularly
care if I get attributed for this fix or any of that.
It Works For Me.
diff -ru linux-2.6.23-rc6-mm1.orig/net/bridge/br_netfilter.c
linux-2.6.23-rc6-mm1/net/bridge/br_netfilter.c
--- linux-2.6.23-rc6-mm1.orig/net/bridge/br_netfilter.c 2007-09-19
02:40:49.0 -0400
+++ linux-2.6.23-rc6-mm1/net/bridge/br_netfilter.c 2007-09-20
20:31:41.0 -0400
@@ -904,7 +904,6 @@
static ctl_table brnf_table[] = {
{
- .ctl_name = NET_BRIDGE_NF_CALL_ARPTABLES,
.procname = "bridge-nf-call-arptables",
.data = _call_arptables,
.maxlen = sizeof(int),
@@ -912,7 +911,6 @@
.proc_handler = _sysctl_call_tables,
},
{
- .ctl_name = NET_BRIDGE_NF_CALL_IPTABLES,
.procname = "bridge-nf-call-iptables",
.data = _call_iptables,
.maxlen = sizeof(int),
@@ -920,7 +918,6 @@
.proc_handler = _sysctl_call_tables,
},
{
- .ctl_name = NET_BRIDGE_NF_CALL_IP6TABLES,
.procname = "bridge-nf-call-ip6tables",
.data = _call_ip6tables,
.maxlen = sizeof(int),
@@ -928,7 +925,6 @@
.proc_handler = _sysctl_call_tables,
},
{
- .ctl_name = NET_BRIDGE_NF_FILTER_VLAN_TAGGED,
.procname = "bridge-nf-filter-vlan-tagged",
.data = _filter_vlan_tagged,
.maxlen = sizeof(int),
@@ -936,7 +932,6 @@
.proc_handler = _sysctl_call_tables,
},
{
- .ctl_name = NET_BRIDGE_NF_FILTER_PPPOE_TAGGED,
.procname = "bridge-nf-filter-pppoe-tagged",
.data = _filter_pppoe_tagged,
.maxlen = sizeof(int),
--
Joseph Fannin
[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/
[PATCH] make mv643xx_eth.c build again
The changeset to "Make NAPI polling independent of struct net_device objects" forgot to change a function prototype in mv643xx_eth.c, and also introduced a typo that caused the driver not to build. Signed-off-by: Joseph Fannin <[EMAIL PROTECTED]> --- This is build-tested only. diff -ru linux-2.6.23-rc6-mm1.orig/drivers/net/mv643xx_eth.c linux-2.6.23-rc6-mm1/drivers/net/mv643xx_eth.c --- linux-2.6.23-rc6-mm1.orig/drivers/net/mv643xx_eth.c 2007-09-20 18:17:41.0 -0400 +++ linux-2.6.23-rc6-mm1/drivers/net/mv643xx_eth.c 2007-09-20 18:17:11.0 -0400 @@ -65,7 +65,7 @@ static int mv643xx_eth_change_mtu(struct net_device *, int); static void eth_port_init_mac_tables(unsigned int eth_port_num); #ifdef MV643XX_NAPI -static int mv643xx_poll(struct net_device *dev, int budget); +static int mv643xx_poll(struct napi_struct *napi, int budget); #endif static int ethernet_phy_get(unsigned int eth_port_num); static void ethernet_phy_set(unsigned int eth_port_num, int phy_addr); @@ -561,7 +561,7 @@ /* wait for previous write to complete */ mv_read(MV643XX_ETH_INTERRUPT_MASK_REG(port_num)); - netif_rx_schedule(dev, >napi); + netif_rx_schedule(dev, >napi); } #else if (eth_int_cause & ETH_INT_CAUSE_RX) -- Joseph Fannin [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.23-rc6-mm1
On Thu, Sep 20, 2007 at 09:42:44PM +0530, Kamalesh Babulal wrote:
> On 9/20/07, Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> > On 9/20/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, 19 Sep 2007 19:58:28 -0400
> > > [EMAIL PROTECTED] (Joseph Fannin) wrote:
> > >
> > > > On Tue, Sep 18, 2007 at 01:18:41AM -0700, Andrew Morton wrote:
> > >
> > > ---
> > > a/include/asm-powerpc/smp.h~convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64-fix-2
> > >
> > > +++ a/include/asm-powerpc/smp.h
> > > @@ -25,8 +25,8 @@
> > >
> > > #ifdef CONFIG_PPC64
> > > #include
> > > -#include
> > > #endif
> > > +#include
> > >
> > > extern int boot_cpuid;
> > Signed-off-by: Kamalesh Babulal <[EMAIL PROTECTED]>
> > ---
> > --- linux-2.6.23-rc6 /drivers/net/mace.c 2007-09-20 17:16:50.0+0530
> > +++ linux-2.6.23-rc6/drivers/net/~mace.c2007-09-20 17:12:
> > 47.0 +0530
> > @@ -633,7 +633,7 @@ static void mace_set_multicast(struct ne
> > spin_unlock_irqrestore(>lock, flags);
> > }
> >
> > -static void mace_handle_misc_intrs(struct mace_data *mp, int intr)
> > +static void mace_handle_misc_intrs(struct mace_data *mp, int intr, struct
> > net_device *dev)
> > {
> > volatile struct mace __iomem *mb = mp->mace;
> > static int mace_babbles, mace_jabbers;
> > @@ -669,7 +669,7 @@ static irqreturn_t mace_interrupt(int ir
> > spin_lock_irqsave(>lock, flags);
> > intr = in_8(>ir); /* read interrupt register */
> > in_8(>xmtrc); /* get retries */
> > -mace_handle_misc_intrs(mp, intr);
> > +mace_handle_misc_intrs(mp, intr, dev);
> >
> > i = mp->tx_empty;
> > while (in_8(>pr) & XMTSV) {
> > @@ -682,7 +682,7 @@ static irqreturn_t mace_interrupt(int ir
> > */
> > intr = in_8(>ir);
> > if (intr != 0)
> > - mace_handle_misc_intrs(mp, intr);
> > + mace_handle_misc_intrs(mp, intr, dev);
> > if (mp->tx_bad_runt) {
> > fs = in_8(>xmtfs);
> > mp->tx_bad_runt = 0;
> > @@ -817,7 +817,7 @@ static void mace_tx_timeout(unsigned lon
> > goto out;
> >
> > /* update various counters */
> > -mace_handle_misc_intrs(mp, in_8(>ir));
> > +mace_handle_misc_intrs(mp, in_8(>ir), dev);
> >
> > cp = mp->tx_cmds + NCMDS_TX * mp->tx_empty;
Both these patches have built and booted for me.
I will send a patch for the following error separately, in what
will hopefully be canonical patch submission format, in case that's of
any use.
Thanks.
> drivers/net/mv643xx_eth.c: In function 'mv643xx_eth_int_handler':
> drivers/net/mv643xx_eth.c:564: error: 'bp' undeclared (first use in this
> function)
> drivers/net/mv643xx_eth.c:564: error: (Each undeclared identifier is
> reported only once
> drivers/net/mv643xx_eth.c:564: error: for each function it appears in.)
> drivers/net/mv643xx_eth.c: At top level:
> drivers/net/mv643xx_eth.c:1010: error: conflicting types for 'mv643xx_poll'
> drivers/net/mv643xx_eth.c:68: error: previous declaration of 'mv643xx_poll'
> was here
> make[2]: *** [drivers/net/mv643xx_eth.o] Error 1
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
--
Joseph Fannin
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] ssb: Make pcmciahost depend on PCMCIA=y
On Thu, Sep 13, 2007 at 10:43:33AM +0900, Paul Mundt wrote: > On Wed, Sep 12, 2007 at 12:59:00PM +0200, Michael Buesch wrote: > > On Wednesday 12 September 2007 12:17:45 Paul Mundt wrote: > > > On Wed, Sep 12, 2007 at 12:09:09PM +0200, Michael Buesch wrote: > > > > There we go. The usual SELECT dependency hell again... > > > > Would changing SSB_PCMCIAHOST_POSSIBLE to tristate also fix it? > > > > What would be the sideeffects? > > > > > > > I tried that first, if you do that you have to change the default to > > > SSB && PCMCIA, and then anything that depends on it also has to be a > > > tristate. That worked ok for SSB_PCMCIAHOST, but it didn't work ok for > > > the b43 wireless + PCMCIA, which is why I opted for the PCMCIA=y thing > > > instead, which makes sure that SSB_PCMCIAHOST can't be enabled if PCMCIA > > > is modular. > > > > Ok, so much for "SELECT is easy and it works if used correctly..." :) > > Well, let's apply that patch then. It needlessly restricts the > > choice to not allow modular pcmcia in that case, though. > > > That is the compromise, yes. Feel free to propose a better solution ;-) I just ran into this link error (CONFIG_PCMCIA=m; CONFIG_SSB_PCMCIAHOST=y). No big deal; I don't have the hardware. But yeah, this is still a problem. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Joseph Fannin [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] ssb: Make pcmciahost depend on PCMCIA=y
On Thu, Sep 13, 2007 at 10:43:33AM +0900, Paul Mundt wrote: On Wed, Sep 12, 2007 at 12:59:00PM +0200, Michael Buesch wrote: On Wednesday 12 September 2007 12:17:45 Paul Mundt wrote: On Wed, Sep 12, 2007 at 12:09:09PM +0200, Michael Buesch wrote: There we go. The usual SELECT dependency hell again... Would changing SSB_PCMCIAHOST_POSSIBLE to tristate also fix it? What would be the sideeffects? I tried that first, if you do that you have to change the default to SSB PCMCIA, and then anything that depends on it also has to be a tristate. That worked ok for SSB_PCMCIAHOST, but it didn't work ok for the b43 wireless + PCMCIA, which is why I opted for the PCMCIA=y thing instead, which makes sure that SSB_PCMCIAHOST can't be enabled if PCMCIA is modular. Ok, so much for SELECT is easy and it works if used correctly... :) Well, let's apply that patch then. It needlessly restricts the choice to not allow modular pcmcia in that case, though. That is the compromise, yes. Feel free to propose a better solution ;-) I just ran into this link error (CONFIG_PCMCIA=m; CONFIG_SSB_PCMCIAHOST=y). No big deal; I don't have the hardware. But yeah, this is still a problem. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Joseph Fannin [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.23-rc6-mm1
On Thu, Sep 20, 2007 at 09:42:44PM +0530, Kamalesh Babulal wrote:
On 9/20/07, Kamalesh Babulal [EMAIL PROTECTED] wrote:
On 9/20/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 19 Sep 2007 19:58:28 -0400
[EMAIL PROTECTED] (Joseph Fannin) wrote:
On Tue, Sep 18, 2007 at 01:18:41AM -0700, Andrew Morton wrote:
---
a/include/asm-powerpc/smp.h~convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64-fix-2
+++ a/include/asm-powerpc/smp.h
@@ -25,8 +25,8 @@
#ifdef CONFIG_PPC64
#include asm/paca.h
-#include asm/percpu.h
#endif
+#include asm/percpu.h
extern int boot_cpuid;
Signed-off-by: Kamalesh Babulal [EMAIL PROTECTED]
---
--- linux-2.6.23-rc6 /drivers/net/mace.c 2007-09-20 17:16:50.0+0530
+++ linux-2.6.23-rc6/drivers/net/~mace.c2007-09-20 17:12:
47.0 +0530
@@ -633,7 +633,7 @@ static void mace_set_multicast(struct ne
spin_unlock_irqrestore(mp-lock, flags);
}
-static void mace_handle_misc_intrs(struct mace_data *mp, int intr)
+static void mace_handle_misc_intrs(struct mace_data *mp, int intr, struct
net_device *dev)
{
volatile struct mace __iomem *mb = mp-mace;
static int mace_babbles, mace_jabbers;
@@ -669,7 +669,7 @@ static irqreturn_t mace_interrupt(int ir
spin_lock_irqsave(mp-lock, flags);
intr = in_8(mb-ir); /* read interrupt register */
in_8(mb-xmtrc); /* get retries */
-mace_handle_misc_intrs(mp, intr);
+mace_handle_misc_intrs(mp, intr, dev);
i = mp-tx_empty;
while (in_8(mb-pr) XMTSV) {
@@ -682,7 +682,7 @@ static irqreturn_t mace_interrupt(int ir
*/
intr = in_8(mb-ir);
if (intr != 0)
- mace_handle_misc_intrs(mp, intr);
+ mace_handle_misc_intrs(mp, intr, dev);
if (mp-tx_bad_runt) {
fs = in_8(mb-xmtfs);
mp-tx_bad_runt = 0;
@@ -817,7 +817,7 @@ static void mace_tx_timeout(unsigned lon
goto out;
/* update various counters */
-mace_handle_misc_intrs(mp, in_8(mb-ir));
+mace_handle_misc_intrs(mp, in_8(mb-ir), dev);
cp = mp-tx_cmds + NCMDS_TX * mp-tx_empty;
Both these patches have built and booted for me.
I will send a patch for the following error separately, in what
will hopefully be canonical patch submission format, in case that's of
any use.
Thanks.
drivers/net/mv643xx_eth.c: In function 'mv643xx_eth_int_handler':
drivers/net/mv643xx_eth.c:564: error: 'bp' undeclared (first use in this
function)
drivers/net/mv643xx_eth.c:564: error: (Each undeclared identifier is
reported only once
drivers/net/mv643xx_eth.c:564: error: for each function it appears in.)
drivers/net/mv643xx_eth.c: At top level:
drivers/net/mv643xx_eth.c:1010: error: conflicting types for 'mv643xx_poll'
drivers/net/mv643xx_eth.c:68: error: previous declaration of 'mv643xx_poll'
was here
make[2]: *** [drivers/net/mv643xx_eth.o] Error 1
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
--
Joseph Fannin
[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/
[PATCH] make mv643xx_eth.c build again
The changeset to Make NAPI polling independent of struct net_device objects forgot to change a function prototype in mv643xx_eth.c, and also introduced a typo that caused the driver not to build. Signed-off-by: Joseph Fannin [EMAIL PROTECTED] --- This is build-tested only. diff -ru linux-2.6.23-rc6-mm1.orig/drivers/net/mv643xx_eth.c linux-2.6.23-rc6-mm1/drivers/net/mv643xx_eth.c --- linux-2.6.23-rc6-mm1.orig/drivers/net/mv643xx_eth.c 2007-09-20 18:17:41.0 -0400 +++ linux-2.6.23-rc6-mm1/drivers/net/mv643xx_eth.c 2007-09-20 18:17:11.0 -0400 @@ -65,7 +65,7 @@ static int mv643xx_eth_change_mtu(struct net_device *, int); static void eth_port_init_mac_tables(unsigned int eth_port_num); #ifdef MV643XX_NAPI -static int mv643xx_poll(struct net_device *dev, int budget); +static int mv643xx_poll(struct napi_struct *napi, int budget); #endif static int ethernet_phy_get(unsigned int eth_port_num); static void ethernet_phy_set(unsigned int eth_port_num, int phy_addr); @@ -561,7 +561,7 @@ /* wait for previous write to complete */ mv_read(MV643XX_ETH_INTERRUPT_MASK_REG(port_num)); - netif_rx_schedule(dev, bp-napi); + netif_rx_schedule(dev, mp-napi); } #else if (eth_int_cause ETH_INT_CAUSE_RX) -- Joseph Fannin [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/
[PATCH] Remove broken netfilter binary sysctls from bridging code
The netfilter sysctls in the bridging code don't set strategy routines:
sysctl table check failed: /net/bridge/bridge-nf-call-arptables .3.10.1
Missing strategy
sysctl table check failed: /net/bridge/bridge-nf-call-iptables .3.10.2 Missing
strategy
sysctl table check failed: /net/bridge/bridge-nf-call-ip6tables .3.10.3
Missing strategy
sysctl table check failed: /net/bridge/bridge-nf-filter-vlan-tagged .3.10.4
Missing strategy
sysctl table check failed: /net/bridge/bridge-nf-filter-pppoe-tagged .3.10.5
Missing strategy
These binary sysctls can't work. The binary sysctl numbers of
other netfilter sysctls with this problem are being removed. These
need to go as well.
Signed-off-by: Joseph Fannin [EMAIL PROTECTED]
---
This *really* needs to be reviewed by someone who knows what this
is all about. I've simply extended the removal of netfilter binary
sysctl numbers so I could load bridge.ko. I don't particularly
care if I get attributed for this fix or any of that.
It Works For Me.
diff -ru linux-2.6.23-rc6-mm1.orig/net/bridge/br_netfilter.c
linux-2.6.23-rc6-mm1/net/bridge/br_netfilter.c
--- linux-2.6.23-rc6-mm1.orig/net/bridge/br_netfilter.c 2007-09-19
02:40:49.0 -0400
+++ linux-2.6.23-rc6-mm1/net/bridge/br_netfilter.c 2007-09-20
20:31:41.0 -0400
@@ -904,7 +904,6 @@
static ctl_table brnf_table[] = {
{
- .ctl_name = NET_BRIDGE_NF_CALL_ARPTABLES,
.procname = bridge-nf-call-arptables,
.data = brnf_call_arptables,
.maxlen = sizeof(int),
@@ -912,7 +911,6 @@
.proc_handler = brnf_sysctl_call_tables,
},
{
- .ctl_name = NET_BRIDGE_NF_CALL_IPTABLES,
.procname = bridge-nf-call-iptables,
.data = brnf_call_iptables,
.maxlen = sizeof(int),
@@ -920,7 +918,6 @@
.proc_handler = brnf_sysctl_call_tables,
},
{
- .ctl_name = NET_BRIDGE_NF_CALL_IP6TABLES,
.procname = bridge-nf-call-ip6tables,
.data = brnf_call_ip6tables,
.maxlen = sizeof(int),
@@ -928,7 +925,6 @@
.proc_handler = brnf_sysctl_call_tables,
},
{
- .ctl_name = NET_BRIDGE_NF_FILTER_VLAN_TAGGED,
.procname = bridge-nf-filter-vlan-tagged,
.data = brnf_filter_vlan_tagged,
.maxlen = sizeof(int),
@@ -936,7 +932,6 @@
.proc_handler = brnf_sysctl_call_tables,
},
{
- .ctl_name = NET_BRIDGE_NF_FILTER_PPPOE_TAGGED,
.procname = bridge-nf-filter-pppoe-tagged,
.data = brnf_filter_pppoe_tagged,
.maxlen = sizeof(int),
--
Joseph Fannin
[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: Hibernating To Swap Considered Harmful
On Mon, Jul 16, 2007 at 11:42:08PM -0700, [EMAIL PROTECTED] wrote: > On Tue, 17 Jul 2007, Joseph Fannin wrote: > >root is free to "dd if=/dev/random of=/dev/mem". Root owned > >daemons which do bad things are bugs. > > in this case it would be more like > > dd if=/block0 of=/dev/sda1 count=1 bs=4096 skip=5000 > dd if=/block1 of=/dev/sda1 count=1 bs=4096 skip=5050 > dd if=/block2 of=/dev/sda1 count=1 bs=4096 skip=5400 > etc > > to write the blocks to the raw parition in the right place What I meant by that was that root is allowed to shoot himself in the foot. Nothing stops root from opening a swap/hibernate file, which would put it in cache, and cause it to be inconsistant if a hibernation image was written to it behind the kernel's back. That would be a very stupid thing to do, however. There's no reason to open that file, unless you know *exactly* what you are doing, in which case the onus is on you to get it right. But you have a point. The swap file could be very fragmented. It might often be so, even. Still, is this better than exporting the kernel's swap internals (which has never been a public interface before)? Does it make the interface that writing hibernation images to swap imposes any better? Even if hibernation files are no less complicated to support than hibernating to swap files (which isn't a forgone conclusion) , there are plenty of reasons writing hibernation images to swap doesn't make sense. > >Again, supporting swap files (*which is not optional*) requires the > >very same support. > > in the kexec model why would the second kernel care about swap files at > all? (unles it chooses to write to them, in which case it is exactly the > same support, but unless it writes to them it doesn't need to care) My point is that no extra work is required to write hibernation images to dedicated files than to write hibernation images to swap files. If swap files are to be supported, then, there's no technical reason not to support dedicated hibernation files. Dedicated hibernation files are better, and there's no reason not to implement them. -- Joseph Fannin [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: Hibernating To Swap Considered Harmful
On Tue, Jul 17, 2007 at 07:44:07AM +0200, Oliver Neukum wrote: > > If yoi want to go the kexec route to hibernation, the dumping kernel > would need to mount the filesystem to write to a file. Therefore the > suspending kernel would need to sync to disk and lock that file. If the file is preallocated, that's not a problem, as there's no need to touch filesystem metadata. There'd need to be some channel to pass the disk blocks that are for writing the image, but that's not going to be nearly as complicated as passing the current swap data structures from the previous kernel. There's no reason to have that file open in the original kernel -- it should be root-owned (it's full of privledged data) and probably mode 000. root is free to "dd if=/dev/random of=/dev/mem". Root owned daemons which do bad things are bugs. Again, supporting swap files (*which is not optional*) requires the very same support. -- Joseph Fannin [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: Hibernating To Swap Considered Harmful
On Tue, Jul 17, 2007 at 07:44:07AM +0200, Oliver Neukum wrote: If yoi want to go the kexec route to hibernation, the dumping kernel would need to mount the filesystem to write to a file. Therefore the suspending kernel would need to sync to disk and lock that file. If the file is preallocated, that's not a problem, as there's no need to touch filesystem metadata. There'd need to be some channel to pass the disk blocks that are for writing the image, but that's not going to be nearly as complicated as passing the current swap data structures from the previous kernel. There's no reason to have that file open in the original kernel -- it should be root-owned (it's full of privledged data) and probably mode 000. root is free to dd if=/dev/random of=/dev/mem. Root owned daemons which do bad things are bugs. Again, supporting swap files (*which is not optional*) requires the very same support. -- Joseph Fannin [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: Hibernating To Swap Considered Harmful
On Mon, Jul 16, 2007 at 11:42:08PM -0700, [EMAIL PROTECTED] wrote: On Tue, 17 Jul 2007, Joseph Fannin wrote: root is free to dd if=/dev/random of=/dev/mem. Root owned daemons which do bad things are bugs. in this case it would be more like dd if=/block0 of=/dev/sda1 count=1 bs=4096 skip=5000 dd if=/block1 of=/dev/sda1 count=1 bs=4096 skip=5050 dd if=/block2 of=/dev/sda1 count=1 bs=4096 skip=5400 etc to write the blocks to the raw parition in the right place What I meant by that was that root is allowed to shoot himself in the foot. Nothing stops root from opening a swap/hibernate file, which would put it in cache, and cause it to be inconsistant if a hibernation image was written to it behind the kernel's back. That would be a very stupid thing to do, however. There's no reason to open that file, unless you know *exactly* what you are doing, in which case the onus is on you to get it right. But you have a point. The swap file could be very fragmented. It might often be so, even. Still, is this better than exporting the kernel's swap internals (which has never been a public interface before)? Does it make the interface that writing hibernation images to swap imposes any better? Even if hibernation files are no less complicated to support than hibernating to swap files (which isn't a forgone conclusion) , there are plenty of reasons writing hibernation images to swap doesn't make sense. Again, supporting swap files (*which is not optional*) requires the very same support. in the kexec model why would the second kernel care about swap files at all? (unles it chooses to write to them, in which case it is exactly the same support, but unless it writes to them it doesn't need to care) My point is that no extra work is required to write hibernation images to dedicated files than to write hibernation images to swap files. If swap files are to be supported, then, there's no technical reason not to support dedicated hibernation files. Dedicated hibernation files are better, and there's no reason not to implement them. -- Joseph Fannin [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: block/bsg.c
On Mon, Jul 16, 2007 at 04:57:06PM -0700, Andrew Morton wrote: > What does the code in bsg.c _do_, anyway?? Ho hum. It reformats the hard drive on Battlestar Galactica before the Cylon virus that has penetrated the firewalls keeps the power off long enough for the Centurions to vent the crew into space. (I believe it used BSG disk slices). -- Joseph Fannin [EMAIL PROTECTED] /me suspects he has used his ration of inanity for about a year or so. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hibernating To Swap Considered Harmful
On Fri, Jul 13, 2007 at 10:35:22AM -0400, Jeremy Maitin-Shepard wrote: > [EMAIL PROTECTED] (Joseph Fannin) writes: > > There is a very simple solution to this obscure problem: (if I > understand correctly, you want to dual boot Mac OS X and Linux (and > maybe also Windows?)) > > use LVM, thus allowing you to have as many volumes as you like in the > partition Ok. Why are all these workarounds preferred, instead of proper suspend support for swap files? IOW, what reasons are there to *not* support swap files, other than the hit-and-miss Linux suspend support? I brought up the swap file issue to illustrate that writing hibernation images to files needs to be supported anyway. Once you have that, there is no good reason to write the hibernation image to swap, and several reasons not to. That my particular problem might be messily worked around isn't really important in the context of that argument, which no one has responded to. (Aside from adding more administrivia to my Macintosh's setup, your LVM suggestion would prevent the ext3 drivers for Windows and OS X from working, as they don't do LVM. This is arguably not Linux's problem -- but Linux *already supports* a working solution). -- Joseph Fannin [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: Hibernating To Swap Considered Harmful
On Fri, Jul 13, 2007 at 10:35:22AM -0400, Jeremy Maitin-Shepard wrote: [EMAIL PROTECTED] (Joseph Fannin) writes: There is a very simple solution to this obscure problem: (if I understand correctly, you want to dual boot Mac OS X and Linux (and maybe also Windows?)) use LVM, thus allowing you to have as many volumes as you like in the partition Ok. Why are all these workarounds preferred, instead of proper suspend support for swap files? IOW, what reasons are there to *not* support swap files, other than the hit-and-miss Linux suspend support? I brought up the swap file issue to illustrate that writing hibernation images to files needs to be supported anyway. Once you have that, there is no good reason to write the hibernation image to swap, and several reasons not to. That my particular problem might be messily worked around isn't really important in the context of that argument, which no one has responded to. (Aside from adding more administrivia to my Macintosh's setup, your LVM suggestion would prevent the ext3 drivers for Windows and OS X from working, as they don't do LVM. This is arguably not Linux's problem -- but Linux *already supports* a working solution). -- Joseph Fannin [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: block/bsg.c
On Mon, Jul 16, 2007 at 04:57:06PM -0700, Andrew Morton wrote: What does the code in bsg.c _do_, anyway?? Ho hum. It reformats the hard drive on Battlestar Galactica before the Cylon virus that has penetrated the firewalls keeps the power off long enough for the Centurions to vent the crew into space. (I believe it used BSG disk slices). -- Joseph Fannin [EMAIL PROTECTED] /me suspects he has used his ration of inanity for about a year or so. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hibernating To Swap Considered Harmful
On Sat, Jul 14, 2007 at 11:48:17AM +0200, Rafael J. Wysocki wrote: > On Saturday, 14 July 2007 02:45, Joseph Fannin wrote: > > On Fri, Jul 13, 2007 at 11:30:50AM +0200, Rafael J. Wysocki wrote: > > > On Friday, 13 July 2007 07:42, Joseph Fannin wrote: > > > > On Thu, Jul 12, 2007 at 08:06:43PM -0700, [EMAIL PROTECTED] wrote: > > > > > > If you're afraid of that, use a dedicated swap file. > > > > I don't understand what you mean. A dedicated swap file for what? > > Sorry, I should have been more precise. > > For hibernation (ie. a swap file that you activate right befor the > hibernation). > > Also tuxonice (formerly known as suspend2) allows you to use regular files > hibernation. How is that different from what I proposed, other than the requirement to pass the swap data stuctures between the two kernels? Even if you only expect hibernation to work only _most of the time_, suspending to swap means allocating a bunch of swap space that you intend to never be used as swap. The two functions don't really belong together. -- Joseph Fannin [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: Hibernating To Swap Considered Harmful
On Sat, Jul 14, 2007 at 11:48:17AM +0200, Rafael J. Wysocki wrote: On Saturday, 14 July 2007 02:45, Joseph Fannin wrote: On Fri, Jul 13, 2007 at 11:30:50AM +0200, Rafael J. Wysocki wrote: On Friday, 13 July 2007 07:42, Joseph Fannin wrote: On Thu, Jul 12, 2007 at 08:06:43PM -0700, [EMAIL PROTECTED] wrote: If you're afraid of that, use a dedicated swap file. I don't understand what you mean. A dedicated swap file for what? Sorry, I should have been more precise. For hibernation (ie. a swap file that you activate right befor the hibernation). Also tuxonice (formerly known as suspend2) allows you to use regular files hibernation. How is that different from what I proposed, other than the requirement to pass the swap data stuctures between the two kernels? Even if you only expect hibernation to work only _most of the time_, suspending to swap means allocating a bunch of swap space that you intend to never be used as swap. The two functions don't really belong together. -- Joseph Fannin [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: Hibernating To Swap Considered Harmful
On Fri, Jul 13, 2007 at 11:30:50AM +0200, Rafael J. Wysocki wrote: > On Friday, 13 July 2007 07:42, Joseph Fannin wrote: > > On Thu, Jul 12, 2007 at 08:06:43PM -0700, [EMAIL PROTECTED] wrote: > > > On Thu, 12 Jul 2007, Rafael J. Wysocki wrote: > > > > > > Plus we need to figure out how to avoid corrupting filesystems and > > > > swap in use by the "old" kernel and its processes (hint: a separate > > > > "hibernation partition" is a no-go). > > > > > > I thought the existing hibernation wrote to the swap partition as it's > > > dedicated space? > > > > > > I didn't know that anyone was suggesting writing the hibernation image to > > > a filesystem that the kernel was activly accessing. > > > > I'm suggesting a dedicated, preallocated hibernation *file*, right > > now. There's no way around it, if hibernation is to be reliable -- > > otherwise hibernation can fail if the system has used enough of its > > swap space, so that there isn't enough room to write the hibernate > > image. > > > > Even if it's desirable to allow hibernation to fail if the system is > > too deep into swap, it's a moot point. > > If you're afraid of that, use a dedicated swap file. I don't understand what you mean. A dedicated swap file for what? -- Joseph Fannin [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: Hibernating To Swap Considered Harmful
On Thu, Jul 12, 2007 at 11:27:41PM -0700, [EMAIL PROTECTED] wrote: > On Fri, 13 Jul 2007, Joseph Fannin wrote: > > >On Thu, Jul 12, 2007 at 10:57:04PM -0700, [EMAIL PROTECTED] wrote: > >>On Fri, 13 Jul 2007, Joseph Fannin wrote: > >> > >>the only justification I have heard for why the hibernate image must be > >>written to the swap partition is backwards compatibility (i.e., we've > >>always done it that way) > >> > >>if you are going to reserve disk space for hibernation, what is so bad > >>about useing a normal partition? > >> > > You have to either repartition when you upgrade your memory, or > >waste a bunch of disk space with a partition as large as you think > >your RAM might ever expand to. > > memory upgrades are rare and tools are available nowdays to resize linux > partitions. I was recently involved in a week long headache that resulted from a botched filesystem resizing. I didn't have backups (most people don't) and I lost a lot. I did get the chance to recreate my ext3 filesystem with 256k inodes, as seen in ext4. Other than the kernel and e2fsprogs, every tool I point at the new filesystem pukes and dies, in no particular order. So: bring a system down for hours to perform a dangerous operation with tools that may be out of date, or spend five minutes with "dd" as root on a running system -- making use of features supported by the kernel for years? Some people think memory changes are important enough to write code to allow memory hotplug. My hardware doesn't support that, but some people have been bandying about the idea of hibernate->hardware change->resume. > > Swap/hibernate files can be created, deleted, and resized without > >partitioning. > > if you just use the hibernate file as a reserved set of blocks and never > touch them from the main OS things will work, but if you do anything that > could put those blocks into the OS write cache all bets are off. Well don't do that then. No one should have permission to open those files anyway, they're full of privledged data, just like the nodes in /dev. If the kernel's caching swap, that's... just perverse. > > Also: not all platforms support a large number of partitions. > >It's not academic -- Intel Macintoshes are limited to four, with two > >taken by Mac OS. Add Windows and a Linux /, and you're out -- > >there's no room for a swap file. > > interesting, I didn't know that. I know that the Tivo's use Mac style > partition tables and they have many partitions (10+). it seems odd that > when switching from powerpc to x86 that they would lock themselves down > like that. are you sure that they can't have extended partitions like > standard PC's? it seems odd that they would have such a special partition > table type if windows can access it. Intel Macs use GPT partition tables, which support a huge number of primary partitions, and so don't support secondary partitions. 32bit Windows does not support GPT, so PC-style MBR partition tables must also be used. GPT was designed to coexist with MBR tools, so this mostly works, but you're limited to the union of supported features -- 4 primary partitions, no secondaries. -- Joseph Fannin [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: Hibernating To Swap Considered Harmful
On Thu, Jul 12, 2007 at 10:57:04PM -0700, [EMAIL PROTECTED] wrote: > On Fri, 13 Jul 2007, Joseph Fannin wrote: > > the only justification I have heard for why the hibernate image must be > written to the swap partition is backwards compatibility (i.e., we've > always done it that way) > > if you are going to reserve disk space for hibernation, what is so bad > about useing a normal partition? > You have to either repartition when you upgrade your memory, or waste a bunch of disk space with a partition as large as you think your RAM might ever expand to. Swap/hibernate files can be created, deleted, and resized without partitioning. Also: not all platforms support a large number of partitions. It's not academic -- Intel Macintoshes are limited to four, with two taken by Mac OS. Add Windows and a Linux /, and you're out -- there's no room for a swap file. -- Joseph Fannin [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: Hibernating To Swap Considered Harmful
On Thu, Jul 12, 2007 at 10:57:04PM -0700, [EMAIL PROTECTED] wrote: On Fri, 13 Jul 2007, Joseph Fannin wrote: the only justification I have heard for why the hibernate image must be written to the swap partition is backwards compatibility (i.e., we've always done it that way) if you are going to reserve disk space for hibernation, what is so bad about useing a normal partition? You have to either repartition when you upgrade your memory, or waste a bunch of disk space with a partition as large as you think your RAM might ever expand to. Swap/hibernate files can be created, deleted, and resized without partitioning. Also: not all platforms support a large number of partitions. It's not academic -- Intel Macintoshes are limited to four, with two taken by Mac OS. Add Windows and a Linux /, and you're out -- there's no room for a swap file. -- Joseph Fannin [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: Hibernating To Swap Considered Harmful
On Thu, Jul 12, 2007 at 11:27:41PM -0700, [EMAIL PROTECTED] wrote: On Fri, 13 Jul 2007, Joseph Fannin wrote: On Thu, Jul 12, 2007 at 10:57:04PM -0700, [EMAIL PROTECTED] wrote: On Fri, 13 Jul 2007, Joseph Fannin wrote: the only justification I have heard for why the hibernate image must be written to the swap partition is backwards compatibility (i.e., we've always done it that way) if you are going to reserve disk space for hibernation, what is so bad about useing a normal partition? You have to either repartition when you upgrade your memory, or waste a bunch of disk space with a partition as large as you think your RAM might ever expand to. memory upgrades are rare and tools are available nowdays to resize linux partitions. I was recently involved in a week long headache that resulted from a botched filesystem resizing. I didn't have backups (most people don't) and I lost a lot. I did get the chance to recreate my ext3 filesystem with 256k inodes, as seen in ext4. Other than the kernel and e2fsprogs, every tool I point at the new filesystem pukes and dies, in no particular order. So: bring a system down for hours to perform a dangerous operation with tools that may be out of date, or spend five minutes with dd as root on a running system -- making use of features supported by the kernel for years? Some people think memory changes are important enough to write code to allow memory hotplug. My hardware doesn't support that, but some people have been bandying about the idea of hibernate-hardware change-resume. Swap/hibernate files can be created, deleted, and resized without partitioning. if you just use the hibernate file as a reserved set of blocks and never touch them from the main OS things will work, but if you do anything that could put those blocks into the OS write cache all bets are off. Well don't do that then. No one should have permission to open those files anyway, they're full of privledged data, just like the nodes in /dev. If the kernel's caching swap, that's... just perverse. Also: not all platforms support a large number of partitions. It's not academic -- Intel Macintoshes are limited to four, with two taken by Mac OS. Add Windows and a Linux /, and you're out -- there's no room for a swap file. interesting, I didn't know that. I know that the Tivo's use Mac style partition tables and they have many partitions (10+). it seems odd that when switching from powerpc to x86 that they would lock themselves down like that. are you sure that they can't have extended partitions like standard PC's? it seems odd that they would have such a special partition table type if windows can access it. Intel Macs use GPT partition tables, which support a huge number of primary partitions, and so don't support secondary partitions. 32bit Windows does not support GPT, so PC-style MBR partition tables must also be used. GPT was designed to coexist with MBR tools, so this mostly works, but you're limited to the union of supported features -- 4 primary partitions, no secondaries. -- Joseph Fannin [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: Hibernating To Swap Considered Harmful
On Fri, Jul 13, 2007 at 11:30:50AM +0200, Rafael J. Wysocki wrote: On Friday, 13 July 2007 07:42, Joseph Fannin wrote: On Thu, Jul 12, 2007 at 08:06:43PM -0700, [EMAIL PROTECTED] wrote: On Thu, 12 Jul 2007, Rafael J. Wysocki wrote: Plus we need to figure out how to avoid corrupting filesystems and swap in use by the old kernel and its processes (hint: a separate hibernation partition is a no-go). I thought the existing hibernation wrote to the swap partition as it's dedicated space? I didn't know that anyone was suggesting writing the hibernation image to a filesystem that the kernel was activly accessing. I'm suggesting a dedicated, preallocated hibernation *file*, right now. There's no way around it, if hibernation is to be reliable -- otherwise hibernation can fail if the system has used enough of its swap space, so that there isn't enough room to write the hibernate image. Even if it's desirable to allow hibernation to fail if the system is too deep into swap, it's a moot point. If you're afraid of that, use a dedicated swap file. I don't understand what you mean. A dedicated swap file for what? -- Joseph Fannin [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/
Hibernating To Swap Considered Harmful
On Thu, Jul 12, 2007 at 08:06:43PM -0700, [EMAIL PROTECTED] wrote: > On Thu, 12 Jul 2007, Rafael J. Wysocki wrote: > > Plus we need to figure out how to avoid corrupting filesystems and > > swap in use by the "old" kernel and its processes (hint: a separate > > "hibernation partition" is a no-go). > > I thought the existing hibernation wrote to the swap partition as it's > dedicated space? > > I didn't know that anyone was suggesting writing the hibernation image to > a filesystem that the kernel was activly accessing. I'm suggesting a dedicated, preallocated hibernation *file*, right now. There's no way around it, if hibernation is to be reliable -- otherwise hibernation can fail if the system has used enough of its swap space, so that there isn't enough room to write the hibernate image. Even if it's desirable to allow hibernation to fail if the system is too deep into swap, it's a moot point. Consider how the need to ensure that there is enough space to write the hibernate image is dealt with now: by making a big honking swap space, so big that enough of it is all but guaranteed to be free, except under the heaviest of memory usage. So the space is already reserved -- and now that it's commingled with actual swap, you have the need to pass the swap data structures between the two kernels. Consider instead, you set up two swap spaces, one regular, and one for hibernation. You don't touch the "hibernation swap" unless the other is full -- I think just setting a lower priority on the swap space is enough for this. Before you jump to the hibernate kernel, you swapoff that hibernate swap. If you can't swapoff the hibernate swap, hibernate fails right there. If you can, you have your space for writing the image, free and clear of any of the original kernel's internal state. There isn't any need to treat that space as swap any more at all -- the only reason to do so would be to reuse the existing code. Setting aside two partitions for swap is obviously undesireable, but thankfully, Linux supports swap *files*. There hasn't been a performance penalty to using a swap file (vs. a partition) since sometime in the 2.5 series. Well, swap files can be fragmented, but that needs to be considered against the *guaranteed* seeks you'll see with a swap partition on the same disk as a busy filesystem, as is the usual case. The only reasons I can see that Linux usually uses a single swap partition are that that's how it's always been done, and because swsusp doesn't support anything other than a single swap device. So, despite Linux supporting those things, you can't actually use a swap file or (or more than one swap device) if you want hibernation support. (Suspend2 has supported swap files for a long time, and I think I heard that uswsusp supports them now too.) Once you accept that swap files need to be supported, you're already going to be supporting everything you need to support a dedicated hibernation file -- if you don't consider the trouble to share the swap and hibernate space to be worth the gain. -- Joseph Fannin [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/
Hibernating To Swap Considered Harmful
On Thu, Jul 12, 2007 at 08:06:43PM -0700, [EMAIL PROTECTED] wrote: On Thu, 12 Jul 2007, Rafael J. Wysocki wrote: Plus we need to figure out how to avoid corrupting filesystems and swap in use by the old kernel and its processes (hint: a separate hibernation partition is a no-go). I thought the existing hibernation wrote to the swap partition as it's dedicated space? I didn't know that anyone was suggesting writing the hibernation image to a filesystem that the kernel was activly accessing. I'm suggesting a dedicated, preallocated hibernation *file*, right now. There's no way around it, if hibernation is to be reliable -- otherwise hibernation can fail if the system has used enough of its swap space, so that there isn't enough room to write the hibernate image. Even if it's desirable to allow hibernation to fail if the system is too deep into swap, it's a moot point. Consider how the need to ensure that there is enough space to write the hibernate image is dealt with now: by making a big honking swap space, so big that enough of it is all but guaranteed to be free, except under the heaviest of memory usage. So the space is already reserved -- and now that it's commingled with actual swap, you have the need to pass the swap data structures between the two kernels. Consider instead, you set up two swap spaces, one regular, and one for hibernation. You don't touch the hibernation swap unless the other is full -- I think just setting a lower priority on the swap space is enough for this. Before you jump to the hibernate kernel, you swapoff that hibernate swap. If you can't swapoff the hibernate swap, hibernate fails right there. If you can, you have your space for writing the image, free and clear of any of the original kernel's internal state. There isn't any need to treat that space as swap any more at all -- the only reason to do so would be to reuse the existing code. Setting aside two partitions for swap is obviously undesireable, but thankfully, Linux supports swap *files*. There hasn't been a performance penalty to using a swap file (vs. a partition) since sometime in the 2.5 series. Well, swap files can be fragmented, but that needs to be considered against the *guaranteed* seeks you'll see with a swap partition on the same disk as a busy filesystem, as is the usual case. The only reasons I can see that Linux usually uses a single swap partition are that that's how it's always been done, and because swsusp doesn't support anything other than a single swap device. So, despite Linux supporting those things, you can't actually use a swap file or (or more than one swap device) if you want hibernation support. (Suspend2 has supported swap files for a long time, and I think I heard that uswsusp supports them now too.) Once you accept that swap files need to be supported, you're already going to be supporting everything you need to support a dedicated hibernation file -- if you don't consider the trouble to share the swap and hibernate space to be worth the gain. -- Joseph Fannin [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc4-mm2
On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ I don't think this was intentional: [ 29.873254] edac_stub: module license 'unspecified' taints kernel. -- Joseph Fannin [EMAIL PROTECTED] || [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc4-mm2
On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ I don't think this was intentional: [ 29.873254] edac_stub: module license 'unspecified' taints kernel. -- Joseph Fannin [EMAIL PROTECTED] || [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: Size of kernel modules
On Wed, Jun 06, 2007 at 05:05:34PM +0200, Christoph Pleger wrote: > I found out that the filenames are the same, but the size of the files > differs very much. I found a module file in the new directory that was > almost five times as large as the file with the same name in the old > directory. For some reason I haven't looked into, copying the Ubuntu .config file always results in having "Build the kernel with debug info" set, which makes the resulting kernel huge. Ubuntu's distributed kernel binary certainly doesn't have this stuff built in, so turn it off in the "Kernel Hacking" menu. If you find that your new kernel spews a lot of messages like "PM: adding device nobus:yourmom", flip "Power Management Debugging" off under the "Power management" menu also. I wouldn't do this preemptively, though -- it turns off other stuff too, and I think Ubuntu's kernel is patched not to do that (and newer kernels have the options separated, I think). Flipping the option and building a new package is pretty quick -- it doesn't rebuild much. -- Joseph Fannin [EMAIL PROTECTED] || [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: Size of kernel modules
On Wed, Jun 06, 2007 at 05:05:34PM +0200, Christoph Pleger wrote: I found out that the filenames are the same, but the size of the files differs very much. I found a module file in the new directory that was almost five times as large as the file with the same name in the old directory. For some reason I haven't looked into, copying the Ubuntu .config file always results in having Build the kernel with debug info set, which makes the resulting kernel huge. Ubuntu's distributed kernel binary certainly doesn't have this stuff built in, so turn it off in the Kernel Hacking menu. If you find that your new kernel spews a lot of messages like PM: adding device nobus:yourmom, flip Power Management Debugging off under the Power management menu also. I wouldn't do this preemptively, though -- it turns off other stuff too, and I think Ubuntu's kernel is patched not to do that (and newer kernels have the options separated, I think). Flipping the option and building a new package is pretty quick -- it doesn't rebuild much. -- Joseph Fannin [EMAIL PROTECTED] || [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: 4Gb ram not showing up
On Tue, Jun 05, 2007 at 09:12:00AM -0400, Tom Moore wrote: > Ok, so it appears that this one is wrong also. If someone could explain > the rules that apply, I would be happy to prepare a patch to the Kconfig > script. I don't consider myself to be completely stupid, and if the > help text was a bit more clear I wouldn't be asking these questions. > I'm sure that other pilgrims will follow along later with the same > questions. If you do create such a patch, please also state that HIGHMEM64G is necessary for support of the NX bit (on those processors that support it). ISTR that a similar issue exists in the NOHIGHMEM case, where some 150MB or so of RAM would be unusable in a 1GB machine with NOHIGHMEM. I could be mis-remembering, that, though. -- Joseph Fannin [EMAIL PROTECTED] || [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: 4Gb ram not showing up
On Tue, Jun 05, 2007 at 09:12:00AM -0400, Tom Moore wrote: Ok, so it appears that this one is wrong also. If someone could explain the rules that apply, I would be happy to prepare a patch to the Kconfig script. I don't consider myself to be completely stupid, and if the help text was a bit more clear I wouldn't be asking these questions. I'm sure that other pilgrims will follow along later with the same questions. If you do create such a patch, please also state that HIGHMEM64G is necessary for support of the NX bit (on those processors that support it). ISTR that a similar issue exists in the NOHIGHMEM case, where some 150MB or so of RAM would be unusable in a 1GB machine with NOHIGHMEM. I could be mis-remembering, that, though. -- Joseph Fannin [EMAIL PROTECTED] || [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1: evm BUG when reading sysfs file
On Fri, May 25, 2007 at 10:28:22PM -0400, Reiner Sailer wrote: > On Tue, 22 May 2007 03:25:48 -0400 > [EMAIL PROTECTED] (Joseph Fannin) wrote: > > > I've been getting this since 2.6.21-rc7-mm1: > > [2.379310] BUG: unable to handle kernel paging request at virtual > > address 4400d340 > > [2.379491] printing eip: > > [2.379573] c021c978 > > [2.379656] *pdpt = 0353c001 > > [2.379739] *pde = > > [2.379824] Oops: [#1] > > [2.379906] PREEMPT SMP > > [2.380059] Modules linked in: thermal processor dm_mod > > [2.380288] CPU:0 > > [2.380289] EIP:0060:[]Not tainted VLI > > [2.380291] EFLAGS: 00010297 (2.6.22-rc1-mm1 #2) > > [2.380547] EIP is at vsnprintf+0x448/0x5d0 > > [2.380633] eax: 4400d340 ebx: c348f034 ecx: 4400d340 edx: fffe > > [2.380721] esi: c03e0100 edi: 4400d340 ebp: c357ecc0 esp: c357ec68 > > [2.380810] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > > [2.380898] Process udevtrigger (pid: 686, ti=c357e000 task=c1876df0 > > task.ti=c357e000) > > [2.380987] Stack: c348f014 0fec c03e1c60 c03e3cec c357eccc c0499b88 > > c357ece0 c0282513 > > [2.381428]c348f014 0fec 3cb70fcb c348f034 > > > > [2.381867] fffe c03e017c c357ed18 0034 c0494a20 > > c357ece0 c021cb9f > > [2.382305] Call Trace: > > [2.382470] [] sprintf+0x1f/0x30 > > [2.382594] [] show_uevent+0xed/0x130 > > [2.382720] [] dev_attr_show+0x23/0x30 > > [2.382843] [] sysfs_read_file+0x97/0x140 > > [2.382968] [] vfs_read+0xaf/0x180 > > [2.383096] [] kernel_read+0x3a/0x50 > > [2.383221] [] evm_calc_hash+0x11c/0x240 > > [2.383347] [] evm_file_free+0xb9/0x330 > > [2.383470] [] __fput+0xba/0x180 > > [2.383593] [] fput+0x22/0x40 > > [2.383715] [] filp_close+0x47/0x70 > > [2.383839] [] sys_close+0x69/0xc0 > > [2.383965] [] syscall_call+0x7/0xb > > [2.384092] [] 0xb7ebd0a7 > > [2.384212] === > > [2.384295] INFO: lockdep is turned off. > > [2.384379] Code: 21 fd ff ff c6 03 25 e9 19 fd ff ff 8d 4f 04 b8 > > 3b a2 3d c0 8b 55 e4 89 4d 08 8b 3f 81 ff ff 0f 00 00 0f 46 f8 89 f9 > > 89 c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 89 c6 8b 45 e0 > > f6 45 > > [2.386787] EIP: [] vsnprintf+0x448/0x5d0 SS:ESP > > 0068:c357ec68 > > Joseph, > > thank you for posting this problem. I cannot reconstruct it on my machine. > > Could you tell us which kernel configuration you used (drivers/char/tpm > and security settings) ? > Does it disappear when IMA is disabled in the kernel config? I've found that disabling CONFIG_SYSFS_DEPRECATED makes the BUG message go away; maybe that's what you're missing? I've also attached my .config -- but it has lots of stuff turned on, so it may be faster to try flipping CONFIG_SYSFS_DEPRECATED on a slimmer config, if you'd like. Disabling IMA doesn't change the message; it's still there. Thanks! -- Joseph Fannin [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1: evm BUG when reading sysfs file
On Fri, May 25, 2007 at 10:28:22PM -0400, Reiner Sailer wrote: On Tue, 22 May 2007 03:25:48 -0400 [EMAIL PROTECTED] (Joseph Fannin) wrote: I've been getting this since 2.6.21-rc7-mm1: [2.379310] BUG: unable to handle kernel paging request at virtual address 4400d340 [2.379491] printing eip: [2.379573] c021c978 [2.379656] *pdpt = 0353c001 [2.379739] *pde = [2.379824] Oops: [#1] [2.379906] PREEMPT SMP [2.380059] Modules linked in: thermal processor dm_mod [2.380288] CPU:0 [2.380289] EIP:0060:[c021c978]Not tainted VLI [2.380291] EFLAGS: 00010297 (2.6.22-rc1-mm1 #2) [2.380547] EIP is at vsnprintf+0x448/0x5d0 [2.380633] eax: 4400d340 ebx: c348f034 ecx: 4400d340 edx: fffe [2.380721] esi: c03e0100 edi: 4400d340 ebp: c357ecc0 esp: c357ec68 [2.380810] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [2.380898] Process udevtrigger (pid: 686, ti=c357e000 task=c1876df0 task.ti=c357e000) [2.380987] Stack: c348f014 0fec c03e1c60 c03e3cec c357eccc c0499b88 c357ece0 c0282513 [2.381428]c348f014 0fec 3cb70fcb c348f034 [2.381867] fffe c03e017c c357ed18 0034 c0494a20 c357ece0 c021cb9f [2.382305] Call Trace: [2.382470] [c021cb9f] sprintf+0x1f/0x30 [2.382594] [c02815ed] show_uevent+0xed/0x130 [2.382720] [c0281163] dev_attr_show+0x23/0x30 [2.382843] [c01dc077] sysfs_read_file+0x97/0x140 [2.382968] [c019502f] vfs_read+0xaf/0x180 [2.383096] [c0198c3a] kernel_read+0x3a/0x50 [2.383221] [c01f126c] evm_calc_hash+0x11c/0x240 [2.383347] [c01efd39] evm_file_free+0xb9/0x330 [2.383470] [c0195a3a] __fput+0xba/0x180 [2.383593] [c0195c32] fput+0x22/0x40 [2.383715] [c0192e07] filp_close+0x47/0x70 [2.383839] [c0194109] sys_close+0x69/0xc0 [2.383965] [c01043c8] syscall_call+0x7/0xb [2.384092] [b7ebd0a7] 0xb7ebd0a7 [2.384212] === [2.384295] INFO: lockdep is turned off. [2.384379] Code: 21 fd ff ff c6 03 25 e9 19 fd ff ff 8d 4f 04 b8 3b a2 3d c0 8b 55 e4 89 4d 08 8b 3f 81 ff ff 0f 00 00 0f 46 f8 89 f9 89 c8 eb 06 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 89 c6 8b 45 e0 f6 45 [2.386787] EIP: [c021c978] vsnprintf+0x448/0x5d0 SS:ESP 0068:c357ec68 Joseph, thank you for posting this problem. I cannot reconstruct it on my machine. Could you tell us which kernel configuration you used (drivers/char/tpm and security settings) ? Does it disappear when IMA is disabled in the kernel config? I've found that disabling CONFIG_SYSFS_DEPRECATED makes the BUG message go away; maybe that's what you're missing? I've also attached my .config -- but it has lots of stuff turned on, so it may be faster to try flipping CONFIG_SYSFS_DEPRECATED on a slimmer config, if you'd like. Disabling IMA doesn't change the message; it's still there. Thanks! -- Joseph Fannin [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1: evm BUG when reading sysfs file
On Tue, May 15, 2007 at 08:19:14PM -0700, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/ I've been getting this since 2.6.21-rc7-mm1: [2.379310] BUG: unable to handle kernel paging request at virtual address 4400d340 [2.379491] printing eip: [2.379573] c021c978 [2.379656] *pdpt = 0353c001 [2.379739] *pde = [2.379824] Oops: [#1] [2.379906] PREEMPT SMP [2.380059] Modules linked in: thermal processor dm_mod [2.380288] CPU:0 [2.380289] EIP:0060:[]Not tainted VLI [2.380291] EFLAGS: 00010297 (2.6.22-rc1-mm1 #2) [2.380547] EIP is at vsnprintf+0x448/0x5d0 [2.380633] eax: 4400d340 ebx: c348f034 ecx: 4400d340 edx: fffe [2.380721] esi: c03e0100 edi: 4400d340 ebp: c357ecc0 esp: c357ec68 [2.380810] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [2.380898] Process udevtrigger (pid: 686, ti=c357e000 task=c1876df0 task.ti=c357e000) [2.380987] Stack: c348f014 0fec c03e1c60 c03e3cec c357eccc c0499b88 c357ece0 c0282513 [2.381428]c348f014 0fec 3cb70fcb c348f034 [2.381867] fffe c03e017c c357ed18 0034 c0494a20 c357ece0 c021cb9f [2.382305] Call Trace: [2.382470] [] sprintf+0x1f/0x30 [2.382594] [] show_uevent+0xed/0x130 [2.382720] [] dev_attr_show+0x23/0x30 [2.382843] [] sysfs_read_file+0x97/0x140 [2.382968] [] vfs_read+0xaf/0x180 [2.383096] [] kernel_read+0x3a/0x50 [2.383221] [] evm_calc_hash+0x11c/0x240 [2.383347] [] evm_file_free+0xb9/0x330 [2.383470] [] __fput+0xba/0x180 [2.383593] [] fput+0x22/0x40 [2.383715] [] filp_close+0x47/0x70 [2.383839] [] sys_close+0x69/0xc0 [2.383965] [] syscall_call+0x7/0xb [2.384092] [] 0xb7ebd0a7 [2.384212] === [2.384295] INFO: lockdep is turned off. [2.384379] Code: 21 fd ff ff c6 03 25 e9 19 fd ff ff 8d 4f 04 b8 3b a2 3d c0 8b 55 e4 89 4d 08 8b 3f 81 ff ff 0f 00 00 0f 46 f8 89 f9 89 c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 89 c6 8b 45 e0 f6 45 [2.386787] EIP: [] vsnprintf+0x448/0x5d0 SS:ESP 0068:c357ec68 This comes a bit after IMA bails out successfully, if that's relevant: [1.708761] ima (ima_init): No TPM chip found(rc = -19), activating TPM-bypass! -- Joseph Fannin [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1: evm BUG when reading sysfs file
On Tue, May 15, 2007 at 08:19:14PM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/ I've been getting this since 2.6.21-rc7-mm1: [2.379310] BUG: unable to handle kernel paging request at virtual address 4400d340 [2.379491] printing eip: [2.379573] c021c978 [2.379656] *pdpt = 0353c001 [2.379739] *pde = [2.379824] Oops: [#1] [2.379906] PREEMPT SMP [2.380059] Modules linked in: thermal processor dm_mod [2.380288] CPU:0 [2.380289] EIP:0060:[c021c978]Not tainted VLI [2.380291] EFLAGS: 00010297 (2.6.22-rc1-mm1 #2) [2.380547] EIP is at vsnprintf+0x448/0x5d0 [2.380633] eax: 4400d340 ebx: c348f034 ecx: 4400d340 edx: fffe [2.380721] esi: c03e0100 edi: 4400d340 ebp: c357ecc0 esp: c357ec68 [2.380810] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [2.380898] Process udevtrigger (pid: 686, ti=c357e000 task=c1876df0 task.ti=c357e000) [2.380987] Stack: c348f014 0fec c03e1c60 c03e3cec c357eccc c0499b88 c357ece0 c0282513 [2.381428]c348f014 0fec 3cb70fcb c348f034 [2.381867] fffe c03e017c c357ed18 0034 c0494a20 c357ece0 c021cb9f [2.382305] Call Trace: [2.382470] [c021cb9f] sprintf+0x1f/0x30 [2.382594] [c02815ed] show_uevent+0xed/0x130 [2.382720] [c0281163] dev_attr_show+0x23/0x30 [2.382843] [c01dc077] sysfs_read_file+0x97/0x140 [2.382968] [c019502f] vfs_read+0xaf/0x180 [2.383096] [c0198c3a] kernel_read+0x3a/0x50 [2.383221] [c01f126c] evm_calc_hash+0x11c/0x240 [2.383347] [c01efd39] evm_file_free+0xb9/0x330 [2.383470] [c0195a3a] __fput+0xba/0x180 [2.383593] [c0195c32] fput+0x22/0x40 [2.383715] [c0192e07] filp_close+0x47/0x70 [2.383839] [c0194109] sys_close+0x69/0xc0 [2.383965] [c01043c8] syscall_call+0x7/0xb [2.384092] [b7ebd0a7] 0xb7ebd0a7 [2.384212] === [2.384295] INFO: lockdep is turned off. [2.384379] Code: 21 fd ff ff c6 03 25 e9 19 fd ff ff 8d 4f 04 b8 3b a2 3d c0 8b 55 e4 89 4d 08 8b 3f 81 ff ff 0f 00 00 0f 46 f8 89 f9 89 c8 eb 06 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 89 c6 8b 45 e0 f6 45 [2.386787] EIP: [c021c978] vsnprintf+0x448/0x5d0 SS:ESP 0068:c357ec68 This comes a bit after IMA bails out successfully, if that's relevant: [1.708761] ima (ima_init): No TPM chip found(rc = -19), activating TPM-bypass! -- Joseph Fannin [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] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
On Mon, Apr 30, 2007 at 10:43:10AM -0700, William Lee Irwin III wrote: > + Allocates the stack physically discontiguously and from high > + memory. Furthermore an unmapped guard page follows the stack. > + This is not for end-users. It's intended to trigger fatal > + system errors under various forms of stack abuse. Why is this not for end-users? Will it not trigger anything useful unless set up properly, or is a big performace hit -- and how, or what? All the kernel debug options are underdocumented this way -- I'd like to have as many of them on as I can without absolutely killing performance, (or rather, *you* would) -- but I can never tell without grovelling all over for the info, which... well, I haven't done it yet, anyway. "End-user" is just insufficently defined for anyone compiling their own kernel. Could you add a bit more text here describing what the effect of physically discontiguous high-memory stacks is? An additional frobnitz dereference on every badda-bing badda-bang, likely to double the time it takes to dance the hokey pokey? *shrug* Some of those debug options probably don't get set very often on kernels that are run for more than to see if it boots. -- Joseph Fannin [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] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
On Mon, Apr 30, 2007 at 10:43:10AM -0700, William Lee Irwin III wrote: + Allocates the stack physically discontiguously and from high + memory. Furthermore an unmapped guard page follows the stack. + This is not for end-users. It's intended to trigger fatal + system errors under various forms of stack abuse. Why is this not for end-users? Will it not trigger anything useful unless set up properly, or is a big performace hit -- and how, or what? All the kernel debug options are underdocumented this way -- I'd like to have as many of them on as I can without absolutely killing performance, (or rather, *you* would) -- but I can never tell without grovelling all over for the info, which... well, I haven't done it yet, anyway. End-user is just insufficently defined for anyone compiling their own kernel. Could you add a bit more text here describing what the effect of physically discontiguous high-memory stacks is? An additional frobnitz dereference on every badda-bing badda-bang, likely to double the time it takes to dance the hokey pokey? *shrug* Some of those debug options probably don't get set very often on kernels that are run for more than to see if it boots. -- Joseph Fannin [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.21-rc6-mm1 ima "BUG: held lock freed!"
On Tue, 2007-04-10 at 15:00 -0400, Reiner Sailer wrote:
> Joseph,
>
> we cannot reproduce the BUG you report. We have identified a potential
> source (spinlock around mutex_init). I have attached a small patch that
> removes this lock from the initialization of the hash table. I have
> tested the patch but I cannot verify if this resolves the problem you
> are seeing.
>
> If you can reproduce the problem, would you mind to apply this patch and
> let us know if this solves the problem?
The BUG message no longer appears with this patch applied. It was 100%
reproducible before, so I think this fixed it.
Thanks!
--
Joseph Fannin
[EMAIL PROTECTED] || [EMAIL PROTECTED]
> >I'm seeing this while booting:
> >
> > ima (ima_init): No TPM chip found(rc = -19), activating TPM-bypass!
> >
> > =
> > [ BUG: held lock freed! ]
> > -
> > swapper/1 is freeing memory c04c7660-c04c76a3, with a lock still held
> > there!
> > (ima_queue_lock){--..}, at: [] ima_create_htable+0x10/0x90
> > 1 lock held by swapper/1:
> > #0: (ima_queue_lock){--..}, at: [] ima_create_htable+0x10/0x90
> >
> > stack backtrace:
> > [] dump_trace+0x1d9/0x210
> > [] show_trace_log_lvl+0x1a/0x30
> > [] show_trace+0x12/0x20
> > [] dump_stack+0x16/0x20
> > [] debug_check_no_locks_freed+0x17a/0x180
> > [] debug_mutex_init+0x1f/0x50
> > [] __mutex_init+0x41/0x50
> > [] ima_create_htable+0x7d/0x90
> > [] ima_init+0x3f/0x270
> > [] init_evm+0x1f5/0x250
> > [] kernel_init+0x132/0x320
> > [] kernel_thread_helper+0x7/0x18
> > ===
> >
> >I saw this in -rc5-mm4 also.
> >
> >I couldn't find a contact address in MAINTAINERS, so I've CC'd the
> > two authors listed on top of ima_create_htable.c , as well as the
> > first submitter of the IMA stuff I found in my LKML archive.
> >
> >As an aside, this computer does have (some sort of) TPM chip, but
> > the driver is built as a module, and not loaded at this point (not a
> > worry for me, I don't intend to use it).
> >
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc6-mm1 ima BUG: held lock freed!
On Tue, 2007-04-10 at 15:00 -0400, Reiner Sailer wrote:
Joseph,
we cannot reproduce the BUG you report. We have identified a potential
source (spinlock around mutex_init). I have attached a small patch that
removes this lock from the initialization of the hash table. I have
tested the patch but I cannot verify if this resolves the problem you
are seeing.
If you can reproduce the problem, would you mind to apply this patch and
let us know if this solves the problem?
The BUG message no longer appears with this patch applied. It was 100%
reproducible before, so I think this fixed it.
Thanks!
--
Joseph Fannin
[EMAIL PROTECTED] || [EMAIL PROTECTED]
I'm seeing this while booting:
ima (ima_init): No TPM chip found(rc = -19), activating TPM-bypass!
=
[ BUG: held lock freed! ]
-
swapper/1 is freeing memory c04c7660-c04c76a3, with a lock still held
there!
(ima_queue_lock){--..}, at: [c0202710] ima_create_htable+0x10/0x90
1 lock held by swapper/1:
#0: (ima_queue_lock){--..}, at: [c0202710] ima_create_htable+0x10/0x90
stack backtrace:
[c0105959] dump_trace+0x1d9/0x210
[c01059aa] show_trace_log_lvl+0x1a/0x30
[c0106612] show_trace+0x12/0x20
[c01066d6] dump_stack+0x16/0x20
[c014fd3a] debug_check_no_locks_freed+0x17a/0x180
[c014cdbf] debug_mutex_init+0x1f/0x50
[c0145451] __mutex_init+0x41/0x50
[c020277d] ima_create_htable+0x7d/0x90
[c020286f] ima_init+0x3f/0x270
[c051b765] init_evm+0x1f5/0x250
[c05015d2] kernel_init+0x132/0x320
[c010532f] kernel_thread_helper+0x7/0x18
===
I saw this in -rc5-mm4 also.
I couldn't find a contact address in MAINTAINERS, so I've CC'd the
two authors listed on top of ima_create_htable.c , as well as the
first submitter of the IMA stuff I found in my LKML archive.
As an aside, this computer does have (some sort of) TPM chip, but
the driver is built as a module, and not loaded at this point (not a
worry for me, I don't intend to use it).
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc6-mm1 ima "BUG: held lock freed!"
On Sun, Apr 08, 2007 at 02:35:59PM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/
>
I'm seeing this while booting:
ima (ima_init): No TPM chip found(rc = -19), activating TPM-bypass!
=
[ BUG: held lock freed! ]
-
swapper/1 is freeing memory c04c7660-c04c76a3, with a lock still held there!
(ima_queue_lock){--..}, at: [] ima_create_htable+0x10/0x90
1 lock held by swapper/1:
#0: (ima_queue_lock){--..}, at: [] ima_create_htable+0x10/0x90
stack backtrace:
[] dump_trace+0x1d9/0x210
[] show_trace_log_lvl+0x1a/0x30
[] show_trace+0x12/0x20
[] dump_stack+0x16/0x20
[] debug_check_no_locks_freed+0x17a/0x180
[] debug_mutex_init+0x1f/0x50
[] __mutex_init+0x41/0x50
[] ima_create_htable+0x7d/0x90
[] ima_init+0x3f/0x270
[] init_evm+0x1f5/0x250
[] kernel_init+0x132/0x320
[] kernel_thread_helper+0x7/0x18
===
I saw this in -rc5-mm4 also.
I couldn't find a contact address in MAINTAINERS, so I've CC'd the
two authors listed on top of ima_create_htable.c , as well as the
first submitter of the IMA stuff I found in my LKML archive.
As an aside, this computer does have (some sort of) TPM chip, but
the driver is built as a module, and not loaded at this point (not a
worry for me, I don't intend to use it).
--
Joseph Fannin
[EMAIL PROTECTED] || [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: 2.6.21-rc6-mm1 ima BUG: held lock freed!
On Sun, Apr 08, 2007 at 02:35:59PM -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/
I'm seeing this while booting:
ima (ima_init): No TPM chip found(rc = -19), activating TPM-bypass!
=
[ BUG: held lock freed! ]
-
swapper/1 is freeing memory c04c7660-c04c76a3, with a lock still held there!
(ima_queue_lock){--..}, at: [c0202710] ima_create_htable+0x10/0x90
1 lock held by swapper/1:
#0: (ima_queue_lock){--..}, at: [c0202710] ima_create_htable+0x10/0x90
stack backtrace:
[c0105959] dump_trace+0x1d9/0x210
[c01059aa] show_trace_log_lvl+0x1a/0x30
[c0106612] show_trace+0x12/0x20
[c01066d6] dump_stack+0x16/0x20
[c014fd3a] debug_check_no_locks_freed+0x17a/0x180
[c014cdbf] debug_mutex_init+0x1f/0x50
[c0145451] __mutex_init+0x41/0x50
[c020277d] ima_create_htable+0x7d/0x90
[c020286f] ima_init+0x3f/0x270
[c051b765] init_evm+0x1f5/0x250
[c05015d2] kernel_init+0x132/0x320
[c010532f] kernel_thread_helper+0x7/0x18
===
I saw this in -rc5-mm4 also.
I couldn't find a contact address in MAINTAINERS, so I've CC'd the
two authors listed on top of ima_create_htable.c , as well as the
first submitter of the IMA stuff I found in my LKML archive.
As an aside, this computer does have (some sort of) TPM chip, but
the driver is built as a module, and not loaded at this point (not a
worry for me, I don't intend to use it).
--
Joseph Fannin
[EMAIL PROTECTED] || [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: NAK new drivers without proper power management?
On Fri, Feb 09, 2007 at 08:59:55PM -0500, Lee Revell wrote: > On 2/9/07, Robert Hancock <[EMAIL PROTECTED]> wrote: > >I would disagree that it's a peripheral issue, it's pretty core these > >days, at least for any hardware that you can stuff in a laptop (though a > >fair number of desktops get suspended and resumed these days too). > > Servers are still the most important Linux market, and don't care > about suspend/resume. I would consider implementing suspend./resume > for a driver that will only be used in server or HPC class hardware a > waste of valuable development resources. Please allow me to be offensively blunt for a moment. So, the situation seems to be: 1. The work of the suspend developer who engages the users who put effort into making suspend work on their hardware (bless their addled little heads) often doesn't meet kernel standards, or isn't well enough documented to prove the real *need* for the features and/or hacks that have happened to get actual users' systems sleeping and running again. 2. The swsusp maintainer continues in the belief that as long as their are no bug reports in kernel bugzilla or crossing the (relatively obscure) swsusp mailing lists, it has zarro boogs and meanwhile works on the fourth implementation of suspend support in as many years. It's in CVS on sourceforge. There's no documentation whatsoever. 3. There's another guy who appears to be doing a lot of work, so I shan't leave him out. Like the two developers previously mentioned, he seems to be working pretty hard on the whole thing. The previously mentioned fourth suspend implementation seems to be largely his doing, for good and for ill. 4. "Everybody" knows suspend doesn't work on Linux without a huge amount of tinkering, deep magic, and dead chickens. Only Gentoo users seem to bother; everyone else waits for Ubuntu 12.04 wherein suspend will "just work". The Gentoo users all use swsusp2, as it contains the hacks to work around: 5. All the suspend developers blame the lack of power-management support in drivers for the inablility of Linux to properly suspend on anything that doesn't support APM. 6. Getting proper power-management support in Linux device drivers is not a priority; drivers without any power management support whatsoever should not only be accepted -- they should be merged without comment or complaint. How is working suspend support ever supposed to happen? -- Joseph Fannin [EMAIL PROTECTED] || [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: NAK new drivers without proper power management?
On Fri, Feb 09, 2007 at 08:59:55PM -0500, Lee Revell wrote: On 2/9/07, Robert Hancock [EMAIL PROTECTED] wrote: I would disagree that it's a peripheral issue, it's pretty core these days, at least for any hardware that you can stuff in a laptop (though a fair number of desktops get suspended and resumed these days too). Servers are still the most important Linux market, and don't care about suspend/resume. I would consider implementing suspend./resume for a driver that will only be used in server or HPC class hardware a waste of valuable development resources. Please allow me to be offensively blunt for a moment. So, the situation seems to be: 1. The work of the suspend developer who engages the users who put effort into making suspend work on their hardware (bless their addled little heads) often doesn't meet kernel standards, or isn't well enough documented to prove the real *need* for the features and/or hacks that have happened to get actual users' systems sleeping and running again. 2. The swsusp maintainer continues in the belief that as long as their are no bug reports in kernel bugzilla or crossing the (relatively obscure) swsusp mailing lists, it has zarro boogs and meanwhile works on the fourth implementation of suspend support in as many years. It's in CVS on sourceforge. There's no documentation whatsoever. 3. There's another guy who appears to be doing a lot of work, so I shan't leave him out. Like the two developers previously mentioned, he seems to be working pretty hard on the whole thing. The previously mentioned fourth suspend implementation seems to be largely his doing, for good and for ill. 4. Everybody knows suspend doesn't work on Linux without a huge amount of tinkering, deep magic, and dead chickens. Only Gentoo users seem to bother; everyone else waits for Ubuntu 12.04 wherein suspend will just work. The Gentoo users all use swsusp2, as it contains the hacks to work around: 5. All the suspend developers blame the lack of power-management support in drivers for the inablility of Linux to properly suspend on anything that doesn't support APM. 6. Getting proper power-management support in Linux device drivers is not a priority; drivers without any power management support whatsoever should not only be accepted -- they should be merged without comment or complaint. How is working suspend support ever supposed to happen? -- Joseph Fannin [EMAIL PROTECTED] || [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usbhid quirks for macbook(pro) (was: Re: Fwd: Re: [linux-usb-devel] usb initialization order (usbhid vs. appletouch))
On Fri, 2006-12-08 at 18:19 +0100, Soeren Sonnenburg wrote: > ok, this patch was now in the mactel svn repository since about a month > and I've never ever seen a report about it failing. Also I asked on the > mailinglist for anyone having problems with that and got no answer, > execpt Joseph, the problem you have been seeing might have been that > one: > > http://www.mail-archive.com/mactel-linux-devel@lists.sourceforge.net/msg00129.html > > I would therefore hope it can be applied and thus appear in .20. I am > attaching the version that is now in mactel-svn (which also includes > geyser4 support). I've since gotten my Macbook's trackpad working with the Appletouch driver also, now, so make that no problems, please. I don't know what the problems I was seeing were anymore, but I think it was mostly the difficulty in getting it set up. I understand that this should help fix that, and wish I hadn't tried to hold it up! -- Joseph Fannin [EMAIL PROTECTED] | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usbhid quirks for macbook(pro) (was: Re: Fwd: Re: [linux-usb-devel] usb initialization order (usbhid vs. appletouch))
On Fri, 2006-12-08 at 18:19 +0100, Soeren Sonnenburg wrote: ok, this patch was now in the mactel svn repository since about a month and I've never ever seen a report about it failing. Also I asked on the mailinglist for anyone having problems with that and got no answer, execpt Joseph, the problem you have been seeing might have been that one: http://www.mail-archive.com/mactel-linux-devel@lists.sourceforge.net/msg00129.html I would therefore hope it can be applied and thus appear in .20. I am attaching the version that is now in mactel-svn (which also includes geyser4 support). I've since gotten my Macbook's trackpad working with the Appletouch driver also, now, so make that no problems, please. I don't know what the problems I was seeing were anymore, but I think it was mostly the difficulty in getting it set up. I understand that this should help fix that, and wish I hadn't tried to hold it up! -- Joseph Fannin [EMAIL PROTECTED] | [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: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?
On Wed, Nov 15, 2006 at 11:01:00AM -0800, Ray Lee wrote: > I've come back to my laptop being mostly dead after hours of it being off on > its own (twice now). Mostly dead meaning the keyboard is nearly > non-responsive, but the mouse works great (I'm in X, of course). I say 'nearly > dead' as sysrq-t,b works, so I'm sorta stumped there. (x-session seems to use > netlink, so perhaps that's the connection? ctrl-alt-f[1-7] don't do anything, > however.) This sounds like what my laptop was doing in -rc5, though mine didn't take hours to start acting up. I *think* it was the MSI troubles, causing interrupts to get lost forever. Anyway, it went away in -rc6. I don't have the broadcom hardware. -- Joseph Fannin [EMAIL PROTECTED] || [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: bcm43xx regression 2.6.19rc3 - rc5, rtnl_lock trouble?
On Wed, Nov 15, 2006 at 11:01:00AM -0800, Ray Lee wrote: I've come back to my laptop being mostly dead after hours of it being off on its own (twice now). Mostly dead meaning the keyboard is nearly non-responsive, but the mouse works great (I'm in X, of course). I say 'nearly dead' as sysrq-t,b works, so I'm sorta stumped there. (x-session seems to use netlink, so perhaps that's the connection? ctrl-alt-f[1-7] don't do anything, however.) This sounds like what my laptop was doing in -rc5, though mine didn't take hours to start acting up. I *think* it was the MSI troubles, causing interrupts to get lost forever. Anyway, it went away in -rc6. I don't have the broadcom hardware. -- Joseph Fannin [EMAIL PROTECTED] || [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: 2.6.12.5: psmouse mouse detection doesn't work
On Sun, Aug 21, 2005 at 06:42:23AM +0200, Harald Dunkel wrote: > Hi folks, > > At boot time my Logitech mouse is detected as > > I: Bus=0011 Vendor=0002 Product=0001 Version= > N: Name="PS/2 Generic Mouse" > P: Phys=isa0060/serio1/input0 > H: Handlers=event1 ts0 mouse0 > B: EV=7 > B: KEY=7 0 0 0 0 > B: REL=3 > > After manually reloading psmouse I get the expected > > I: Bus=0011 Vendor=0002 Product=0002 Version=0049 > N: Name="PS2++ Logitech Mouse" > P: Phys=isa0060/serio1/input0 > H: Handlers=event1 ts0 mouse0 > B: EV=7 > B: KEY=f 0 0 0 0 > B: REL=3 > > Using psmouse_noext=1 at boot time does not help. > > How comes that this doesn't work on the first run? > > I asked this more than a year ago, and somebody posted > a fix, but obviously it wasn't accepted. > > What needs to be done to fix this? If psmouse is a module, you'd need to pass proto=bare as a module parameter rather than on the kernel command line. Check `modinfo psmouse`. Are you sure proto=imps hasn't found its way into /etc/modprobe.conf or so? I could imagine a distribution shipping this way. -- Joseph Fannin [EMAIL PROTECTED] /* So there I am, in the middle of my `netfilter-is-wonderful' talk in Sydney, and someone asks `What happens if you try to enlarge a 64k packet here?'. I think I said something eloquent like `fuck'. - RR */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Posix file attribute support on VFAT (take #2)
On Thu, Aug 18, 2005 at 07:52:23PM +0900, Hiroyuki Machida wrote: > Christoph Hellwig wrote: > >On Wed, Aug 17, 2005 at 04:07:03AM +0900, Machida, Hiroyuki wrote: > >>This is a take 2 of posix file attribute support on VFAT. > > > > > >Sorry, but this is far too scary. Please just use one of the sane > >filesystems linux supports. > > > > I would say that purpose of the feature is having ability to > build root fs for small embedded device, not support full posix > attributes top of VFAT. I think the situation is like uclinux, > which has no MMU support and many restriction, however it's still > very helpful for small embedded device. This doesn't seem so different from umsdos to me -- which was only removed from the kernel because it was unmaintained. It might have its place. However, I'd guess you'd need to demonstrate that someone is actually going to use and maintain this feature before it would be considered for inclusion in the kernel. -- Joseph Fannin [EMAIL PROTECTED] "Bull in pure form is rare; there is usually some contamination by data." -- William Graves Perry Jr. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.13-rc6-git10 test report [x86_64](WITHOUT NVIDIA MODULE)
On Fri, Aug 19, 2005 at 09:22:09AM -0700, Peter Buckingham wrote: > >The machine is working quite a bit better with pci=noacpi in leu of > >disabling ACPI in the BIOS, but there are still those nasty errors in > >reference to the ACPI tables being broken: > >ACPI-0362: *** Error: Looking up [\_SB_.PCI0.LNK0] in namespace, > >AE_NOT_FOUND > >search_node 8101428572c0 start_node 8101428572c0 return_node > > > > since it doesn't look like you'll get a bios fix for this you may want > to look at building a custom dsdt. the kernel can load a custom dsdt > from an initrd/initramfs. have a look at the acpi site (acpi.sf.net?). > they talk about what's needed to do this. basically you can get your > dsdt from /proc/acpi/dsdt and disassemble it using the iasl tools, fix > it and then load it with an initrd. note that this is not really a > trivial task :-( Also, please file a bug report against the ACPI component at http://bugzilla.kernel.org . Ultimately the Linux ACPI component must deal with these sorts of errors, or convince the BIOS authors not to make them! -- Joseph Fannin [EMAIL PROTECTED] "That's all I have to say about that." -- Forrest Gump. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.13-rc6-git10 test report [x86_64](WITHOUT NVIDIA MODULE)
On Fri, Aug 19, 2005 at 09:22:09AM -0700, Peter Buckingham wrote: The machine is working quite a bit better with pci=noacpi in leu of disabling ACPI in the BIOS, but there are still those nasty errors in reference to the ACPI tables being broken: ACPI-0362: *** Error: Looking up [\_SB_.PCI0.LNK0] in namespace, AE_NOT_FOUND search_node 8101428572c0 start_node 8101428572c0 return_node since it doesn't look like you'll get a bios fix for this you may want to look at building a custom dsdt. the kernel can load a custom dsdt from an initrd/initramfs. have a look at the acpi site (acpi.sf.net?). they talk about what's needed to do this. basically you can get your dsdt from /proc/acpi/dsdt and disassemble it using the iasl tools, fix it and then load it with an initrd. note that this is not really a trivial task :-( Also, please file a bug report against the ACPI component at http://bugzilla.kernel.org . Ultimately the Linux ACPI component must deal with these sorts of errors, or convince the BIOS authors not to make them! -- Joseph Fannin [EMAIL PROTECTED] That's all I have to say about that. -- Forrest Gump. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Posix file attribute support on VFAT (take #2)
On Thu, Aug 18, 2005 at 07:52:23PM +0900, Hiroyuki Machida wrote: Christoph Hellwig wrote: On Wed, Aug 17, 2005 at 04:07:03AM +0900, Machida, Hiroyuki wrote: This is a take 2 of posix file attribute support on VFAT. Sorry, but this is far too scary. Please just use one of the sane filesystems linux supports. I would say that purpose of the feature is having ability to build root fs for small embedded device, not support full posix attributes top of VFAT. I think the situation is like uclinux, which has no MMU support and many restriction, however it's still very helpful for small embedded device. This doesn't seem so different from umsdos to me -- which was only removed from the kernel because it was unmaintained. It might have its place. However, I'd guess you'd need to demonstrate that someone is actually going to use and maintain this feature before it would be considered for inclusion in the kernel. -- Joseph Fannin [EMAIL PROTECTED] Bull in pure form is rare; there is usually some contamination by data. -- William Graves Perry Jr. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.12.5: psmouse mouse detection doesn't work
On Sun, Aug 21, 2005 at 06:42:23AM +0200, Harald Dunkel wrote: Hi folks, At boot time my Logitech mouse is detected as I: Bus=0011 Vendor=0002 Product=0001 Version= N: Name=PS/2 Generic Mouse P: Phys=isa0060/serio1/input0 H: Handlers=event1 ts0 mouse0 B: EV=7 B: KEY=7 0 0 0 0 B: REL=3 After manually reloading psmouse I get the expected I: Bus=0011 Vendor=0002 Product=0002 Version=0049 N: Name=PS2++ Logitech Mouse P: Phys=isa0060/serio1/input0 H: Handlers=event1 ts0 mouse0 B: EV=7 B: KEY=f 0 0 0 0 B: REL=3 Using psmouse_noext=1 at boot time does not help. How comes that this doesn't work on the first run? I asked this more than a year ago, and somebody posted a fix, but obviously it wasn't accepted. What needs to be done to fix this? If psmouse is a module, you'd need to pass proto=bare as a module parameter rather than on the kernel command line. Check `modinfo psmouse`. Are you sure proto=imps hasn't found its way into /etc/modprobe.conf or so? I could imagine a distribution shipping this way. -- Joseph Fannin [EMAIL PROTECTED] /* So there I am, in the middle of my `netfilter-is-wonderful' talk in Sydney, and someone asks `What happens if you try to enlarge a 64k packet here?'. I think I said something eloquent like `fuck'. - RR */ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sched_yield() makes OpenLDAP slow
On Thu, Aug 18, 2005 at 02:50:16AM +0200, Bernardo Innocenti wrote: > The relative timestamp reveals that slapd is spending 50ms > after yielding. Meanwhile, GCC is probably being scheduled > for a whole quantum. > > Reading the man-page of sched_yield() it seems this isn't > the correct behavior: > >Note: If the current process is the only process in the >highest priority list at that time, this process will >continue to run after a call to sched_yield. The behavior of sched_yield changed for 2.6. I suppose the man page didn't get updated. >From linux/Documentation/post-halloween.txt: | - The behavior of sched_yield() changed a lot. A task that uses | this system call should now expect to sleep for possibly a very | long time. Tasks that do not really desire to give up the | processor for a while should probably not make heavy use of this | function. Unfortunately, some GUI programs (like Open Office) | do make excessive use of this call and under load their | performance is poor. It seems this new 2.6 behavior is optimal | but some user-space applications may need fixing. This is pretty much all I know about it; I just thought I'd point it out. > I also think OpenLDAP is wrong. First, it should be calling > pthread_yield() because slapd is a multithreading process > and it just wants to run the other threads. See: Is it possible that this problem has been noticed and fixed already? -- Joseph Fannin [EMAIL PROTECTED] /* So there I am, in the middle of my `netfilter-is-wonderful' talk in Sydney, and someone asks `What happens if you try to enlarge a 64k packet here?'. I think I said something eloquent like `fuck'. - RR */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sched_yield() makes OpenLDAP slow
On Thu, Aug 18, 2005 at 02:50:16AM +0200, Bernardo Innocenti wrote: The relative timestamp reveals that slapd is spending 50ms after yielding. Meanwhile, GCC is probably being scheduled for a whole quantum. Reading the man-page of sched_yield() it seems this isn't the correct behavior: Note: If the current process is the only process in the highest priority list at that time, this process will continue to run after a call to sched_yield. The behavior of sched_yield changed for 2.6. I suppose the man page didn't get updated. From linux/Documentation/post-halloween.txt: | - The behavior of sched_yield() changed a lot. A task that uses | this system call should now expect to sleep for possibly a very | long time. Tasks that do not really desire to give up the | processor for a while should probably not make heavy use of this | function. Unfortunately, some GUI programs (like Open Office) | do make excessive use of this call and under load their | performance is poor. It seems this new 2.6 behavior is optimal | but some user-space applications may need fixing. This is pretty much all I know about it; I just thought I'd point it out. I also think OpenLDAP is wrong. First, it should be calling pthread_yield() because slapd is a multithreading process and it just wants to run the other threads. See: Is it possible that this problem has been noticed and fixed already? -- Joseph Fannin [EMAIL PROTECTED] /* So there I am, in the middle of my `netfilter-is-wonderful' talk in Sydney, and someone asks `What happens if you try to enlarge a 64k packet here?'. I think I said something eloquent like `fuck'. - RR */ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: captive-ntfs FUSE support?
On Wed, Aug 10, 2005 at 06:15:56PM +0100, Daniel Drake wrote: > As for captive, I don't think its worth the effort. It has severe memory > problems and Linux-NTFS development is going quite fast anyway. I haven't seen any real changes in NTFS support in the kernel since the mid-2.5 series. Is there somewhere else I should be looking? Thanks! -- Joseph Fannin [EMAIL PROTECTED] "Bull in pure form is rare; there is usually some contamination by data." -- William Graves Perry Jr. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: captive-ntfs FUSE support?
On Wed, Aug 10, 2005 at 06:15:56PM +0100, Daniel Drake wrote: As for captive, I don't think its worth the effort. It has severe memory problems and Linux-NTFS development is going quite fast anyway. I haven't seen any real changes in NTFS support in the kernel since the mid-2.5 series. Is there somewhere else I should be looking? Thanks! -- Joseph Fannin [EMAIL PROTECTED] Bull in pure form is rare; there is usually some contamination by data. -- William Graves Perry Jr. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.13-rc3-mm1
On Sat, Jul 16, 2005 at 09:32:49PM -0400, wrote: > On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ > > > +suspend-update-documentation.patch > > +swsusp-fix-printks-and-cleanups.patch > > +swsusp-fix-remaining-u32-vs-pm_message_t-confusion.patch > > +swsusp-switch-pm_message_t-to-struct.patch > > +swsusp-switch-pm_message_t-to-struct-pmac_zilog-fix.patch > > +swsusp-switch-pm_message_t-to-struct-ppc32-fixes.patch > > +fix-pm_message_t-stuff-in-mm-tree-netdev.patch > I needed this little patch too. It's boot-tested; I have a MESH controller. Thanks! - diff -aurN linux-2.6.13-rc3-mm1/drivers/scsi/mesh.c linux-2.6.13-rc3-mm1_changed/drivers/scsi/mesh.c --- linux-2.6.13-rc3-mm1/drivers/scsi/mesh.c2005-07-16 01:46:44.0 -0400 +++ linux-2.6.13-rc3-mm1_changed/drivers/scsi/mesh.c2005-07-18 07:52:04.0 -0400 @@ -1766,7 +1766,7 @@ struct mesh_state *ms = (struct mesh_state *)macio_get_drvdata(mdev); unsigned long flags; - if (state == mdev->ofdev.dev.power.power_state || state < 2) + if (state.event == mdev->ofdev.dev.power.power_state.event || state.event < 2) return 0; scsi_block_requests(ms->host); @@ -1781,7 +1781,7 @@ disable_irq(ms->meshintr); set_mesh_power(ms, 0); - mdev->ofdev.dev.power.power_state = state; + mdev->ofdev.dev.power.power_state.event = state.event; return 0; } @@ -1791,7 +1791,7 @@ struct mesh_state *ms = (struct mesh_state *)macio_get_drvdata(mdev); unsigned long flags; - if (mdev->ofdev.dev.power.power_state == 0) + if (mdev->ofdev.dev.power.power_state.event == 0) return 0; set_mesh_power(ms, 1); @@ -1802,7 +1802,7 @@ enable_irq(ms->meshintr); scsi_unblock_requests(ms->host); - mdev->ofdev.dev.power.power_state = 0; + mdev->ofdev.dev.power.power_state.event = 0; return 0; } -- Joseph Fannin [EMAIL PROTECTED] "That's all I have to say about that." -- Forrest Gump. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.13-rc3-mm1
On Sat, Jul 16, 2005 at 09:32:49PM -0400, wrote: On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ +suspend-update-documentation.patch +swsusp-fix-printks-and-cleanups.patch +swsusp-fix-remaining-u32-vs-pm_message_t-confusion.patch +swsusp-switch-pm_message_t-to-struct.patch +swsusp-switch-pm_message_t-to-struct-pmac_zilog-fix.patch +swsusp-switch-pm_message_t-to-struct-ppc32-fixes.patch +fix-pm_message_t-stuff-in-mm-tree-netdev.patch I needed this little patch too. It's boot-tested; I have a MESH controller. Thanks! - diff -aurN linux-2.6.13-rc3-mm1/drivers/scsi/mesh.c linux-2.6.13-rc3-mm1_changed/drivers/scsi/mesh.c --- linux-2.6.13-rc3-mm1/drivers/scsi/mesh.c2005-07-16 01:46:44.0 -0400 +++ linux-2.6.13-rc3-mm1_changed/drivers/scsi/mesh.c2005-07-18 07:52:04.0 -0400 @@ -1766,7 +1766,7 @@ struct mesh_state *ms = (struct mesh_state *)macio_get_drvdata(mdev); unsigned long flags; - if (state == mdev-ofdev.dev.power.power_state || state 2) + if (state.event == mdev-ofdev.dev.power.power_state.event || state.event 2) return 0; scsi_block_requests(ms-host); @@ -1781,7 +1781,7 @@ disable_irq(ms-meshintr); set_mesh_power(ms, 0); - mdev-ofdev.dev.power.power_state = state; + mdev-ofdev.dev.power.power_state.event = state.event; return 0; } @@ -1791,7 +1791,7 @@ struct mesh_state *ms = (struct mesh_state *)macio_get_drvdata(mdev); unsigned long flags; - if (mdev-ofdev.dev.power.power_state == 0) + if (mdev-ofdev.dev.power.power_state.event == 0) return 0; set_mesh_power(ms, 1); @@ -1802,7 +1802,7 @@ enable_irq(ms-meshintr); scsi_unblock_requests(ms-host); - mdev-ofdev.dev.power.power_state = 0; + mdev-ofdev.dev.power.power_state.event = 0; return 0; } -- Joseph Fannin [EMAIL PROTECTED] That's all I have to say about that. -- Forrest Gump. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.13-rc3-mm1
On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ > +suspend-update-documentation.patch > +swsusp-fix-printks-and-cleanups.patch > +swsusp-fix-remaining-u32-vs-pm_message_t-confusion.patch > +swsusp-switch-pm_message_t-to-struct.patch > +swsusp-switch-pm_message_t-to-struct-pmac_zilog-fix.patch > +swsusp-switch-pm_message_t-to-struct-ppc32-fixes.patch > +fix-pm_message_t-stuff-in-mm-tree-netdev.patch I'm getting this (on ppc32, though I don't think it matters): CC drivers/video/chipsfb.o drivers/video/chipsfb.c: In function `chipsfb_pci_suspend': drivers/video/chipsfb.c:465: error: invalid operands to binary == drivers/video/chipsfb.c:467: error: invalid operands to binary != make[3]: *** [drivers/video/chipsfb.o] Error 1 make[2]: *** [drivers/video] Error 2 make[1]: *** [drivers] Error 2 make[1]: Leaving directory `/usr/src/linux-ctesiphon/linux-2.6.13-rc3-mm1' make: *** [stamp-build] Error 2 The above-quoted patches seem to be the culprit, but my feeble attempts at making a patch didn't work out. While I'm complaining: > Q: Why we cannot suspend to a swap file? > A: Because accessing swap file needs the filesystem mounted, and > filesystem might do something wrong (like replaying the journal) > during mount. [Probably could be solved by modifying every filesystem > to support some kind of "really read-only!" option. Patches welcome.] I seem to recall that swsusp2 can do this. I don't hold out much hope that suspend will ever work on my laptop, with its i815 video chipset, at least not from X (and then there's no point). The i81x and the linux video architecture just don't get along, even if I do away with i810fb and DRM support. But I can't help but notice that every linux-suspend HOWTO tells you to patch in swsusp2 as a first step -- the consensus seems to be that it you want clean and conservative code, use swsusp1; if you want suspending to *work*, use swsusp2. How many people are actually able to make use of swsusp1? Is anyone testing it besides Mr. Machek? This is a case in point; every time I partition a system for Linux, I have to consider whether or not I'm ever going to want swsusp to work on that box. The performance penalty for swap files went away in 2.6, so this is sort of a regression. I know I'm not going to be writing any of those patches, but I'd sure be nice if Linux got around to having usable suspend support without being beholden to the whatever patches Mr. Cunningham gets around to putting out. -- Joseph Fannin [EMAIL PROTECTED] /* So there I am, in the middle of my `netfilter-is-wonderful' talk in Sydney, and someone asks `What happens if you try to enlarge a 64k packet here?'. I think I said something eloquent like `fuck'. - RR */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.13-rc3-mm1
On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ +suspend-update-documentation.patch +swsusp-fix-printks-and-cleanups.patch +swsusp-fix-remaining-u32-vs-pm_message_t-confusion.patch +swsusp-switch-pm_message_t-to-struct.patch +swsusp-switch-pm_message_t-to-struct-pmac_zilog-fix.patch +swsusp-switch-pm_message_t-to-struct-ppc32-fixes.patch +fix-pm_message_t-stuff-in-mm-tree-netdev.patch I'm getting this (on ppc32, though I don't think it matters): CC drivers/video/chipsfb.o drivers/video/chipsfb.c: In function `chipsfb_pci_suspend': drivers/video/chipsfb.c:465: error: invalid operands to binary == drivers/video/chipsfb.c:467: error: invalid operands to binary != make[3]: *** [drivers/video/chipsfb.o] Error 1 make[2]: *** [drivers/video] Error 2 make[1]: *** [drivers] Error 2 make[1]: Leaving directory `/usr/src/linux-ctesiphon/linux-2.6.13-rc3-mm1' make: *** [stamp-build] Error 2 The above-quoted patches seem to be the culprit, but my feeble attempts at making a patch didn't work out. While I'm complaining: Q: Why we cannot suspend to a swap file? A: Because accessing swap file needs the filesystem mounted, and filesystem might do something wrong (like replaying the journal) during mount. [Probably could be solved by modifying every filesystem to support some kind of really read-only! option. Patches welcome.] I seem to recall that swsusp2 can do this. I don't hold out much hope that suspend will ever work on my laptop, with its i815 video chipset, at least not from X (and then there's no point). The i81x and the linux video architecture just don't get along, even if I do away with i810fb and DRM support. But I can't help but notice that every linux-suspend HOWTO tells you to patch in swsusp2 as a first step -- the consensus seems to be that it you want clean and conservative code, use swsusp1; if you want suspending to *work*, use swsusp2. How many people are actually able to make use of swsusp1? Is anyone testing it besides Mr. Machek? This is a case in point; every time I partition a system for Linux, I have to consider whether or not I'm ever going to want swsusp to work on that box. The performance penalty for swap files went away in 2.6, so this is sort of a regression. I know I'm not going to be writing any of those patches, but I'd sure be nice if Linux got around to having usable suspend support without being beholden to the whatever patches Mr. Cunningham gets around to putting out. -- Joseph Fannin [EMAIL PROTECTED] /* So there I am, in the middle of my `netfilter-is-wonderful' talk in Sydney, and someone asks `What happens if you try to enlarge a 64k packet here?'. I think I said something eloquent like `fuck'. - RR */ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.13-rc1-mm1
On Fri, Jul 01, 2005 at 04:40:18AM -0700, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc1/2.6.13-rc1-mm1/ I get this when building on ppc32: CC [M] drivers/net/skge.o drivers/net/skge.c: In function `skge_probe': drivers/net/skge.c:3151: error: `PCI_REV_DESC' undeclared (first use in this function) drivers/net/skge.c:3151: error: (Each undeclared identifier is reported only once drivers/net/skge.c:3151: error: for each function it appears in.) I'm just getting back 'round to building the -mm kernels again, and I haven't tested any previous version, including 2.6.12 or 2.6.13-rc1, but I'm guessing this might have been introduced by the merge of skge stuff from Stephen Hemminger (CC'd) in mainline a week ago. In any case, I don't have the hardware, so deselecting the config option gets me a kernel that builds. My .config is attached, in the case it's useful. -- Joseph Fannin [EMAIL PROTECTED] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.13-rc1-mm1 # Mon Jul 4 08:24:50 2005 # CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_HAVE_DEC_LOCK=y CONFIG_PPC=y CONFIG_PPC32=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y 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 CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y # # Processor # CONFIG_6xx=y # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_POWER3 is not set # CONFIG_POWER4 is not set # CONFIG_8xx is not set # CONFIG_E200 is not set # CONFIG_E500 is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_TAU=y # CONFIG_TAU_INT is not set # CONFIG_TAU_AVERAGE is not set # CONFIG_KEXEC is not set CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m CONFIG_CPU_FREQ_PMAC=y CONFIG_PPC601_SYNC_FIX=y CONFIG_PM=y CONFIG_PPC_STD_MMU=y # # Performance-monitoring counters support # CONFIG_PERFCTR=y # CONFIG_PERFCTR_INIT_TESTS is not set CONFIG_PERFCTR_VIRTUAL=y # CONFIG_PERFCTR_INTERRUPT_SUPPORT is not set # # Platform options # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_APUS is not set # CONFIG_KATANA is not set # CONFIG_WILLOW is not set # CONFIG_CPCI690 is not set # CONFIG_PCORE is not set # CONFIG_POWERPMC250 is not set # CONFIG_CHESTNUT is not set # CONFIG_SPRUCE is not set # CONFIG_HDPU is not set # CONFIG_EV64260 is not set # CONFIG_LOPEC is not set # CONFIG_MCPN765 is not set # CONFIG_MVME5100 is not set # CONFIG_PPLUS is not set # CONFIG_PRPMC750 is not set # CONFIG_PRPMC800 is not set # CONFIG_SANDPOINT is not set # CONFIG_RADSTONE_PPC7D is not set # CONFIG_ADIR is not set # CONFIG_K2 is not set # CONFIG_PAL4 is not set # CONFIG_GEMINI is not set # CONFIG_EST8260 is not set # CONFIG_SBC82xx is not set # CONFIG_SBS8260 is not set # CONFIG_RPX8260 is not set # CONFIG_TQM8260 is not set # CONFIG_ADS8272 is not set # CONFIG_PQ2FADS is not set # CONFIG_LITE5200 is not set # CONFIG_MPC834x_SYS is not set CONFIG_PPC_CHRP=y CONFIG_PPC_PMAC=y CONFIG_PPC_PREP=y CONFIG_PPC_OF=y CONFIG_PPCBUG_NVRAM=y # CONFIG_SMP is not set CONFIG_PREEMPT=y # CONFIG_HIGHMEM is not set CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PROC_DEVICETREE=y CONFIG_PREP_RESIDUAL=y CONFIG_PROC_PREPRESIDUAL=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="console=ttyS0,9600 console=tty0 root=/dev/sda2" # CONFIG_PM_DEBUG is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION="" CONFIG_SECCOMP=y CONFIG_ISA_DMA_API=y # # Bus options # # CONFIG_ISA is not set CONFIG_GENERIC_ISA_DMA
Re: 2.6.13-rc1-mm1
On Fri, Jul 01, 2005 at 04:40:18AM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc1/2.6.13-rc1-mm1/ I get this when building on ppc32: CC [M] drivers/net/skge.o drivers/net/skge.c: In function `skge_probe': drivers/net/skge.c:3151: error: `PCI_REV_DESC' undeclared (first use in this function) drivers/net/skge.c:3151: error: (Each undeclared identifier is reported only once drivers/net/skge.c:3151: error: for each function it appears in.) I'm just getting back 'round to building the -mm kernels again, and I haven't tested any previous version, including 2.6.12 or 2.6.13-rc1, but I'm guessing this might have been introduced by the merge of skge stuff from Stephen Hemminger (CC'd) in mainline a week ago. In any case, I don't have the hardware, so deselecting the config option gets me a kernel that builds. My .config is attached, in the case it's useful. -- Joseph Fannin [EMAIL PROTECTED] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.13-rc1-mm1 # Mon Jul 4 08:24:50 2005 # CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_HAVE_DEC_LOCK=y CONFIG_PPC=y CONFIG_PPC32=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y 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 CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y # # Processor # CONFIG_6xx=y # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_POWER3 is not set # CONFIG_POWER4 is not set # CONFIG_8xx is not set # CONFIG_E200 is not set # CONFIG_E500 is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_TAU=y # CONFIG_TAU_INT is not set # CONFIG_TAU_AVERAGE is not set # CONFIG_KEXEC is not set CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m CONFIG_CPU_FREQ_PMAC=y CONFIG_PPC601_SYNC_FIX=y CONFIG_PM=y CONFIG_PPC_STD_MMU=y # # Performance-monitoring counters support # CONFIG_PERFCTR=y # CONFIG_PERFCTR_INIT_TESTS is not set CONFIG_PERFCTR_VIRTUAL=y # CONFIG_PERFCTR_INTERRUPT_SUPPORT is not set # # Platform options # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_APUS is not set # CONFIG_KATANA is not set # CONFIG_WILLOW is not set # CONFIG_CPCI690 is not set # CONFIG_PCORE is not set # CONFIG_POWERPMC250 is not set # CONFIG_CHESTNUT is not set # CONFIG_SPRUCE is not set # CONFIG_HDPU is not set # CONFIG_EV64260 is not set # CONFIG_LOPEC is not set # CONFIG_MCPN765 is not set # CONFIG_MVME5100 is not set # CONFIG_PPLUS is not set # CONFIG_PRPMC750 is not set # CONFIG_PRPMC800 is not set # CONFIG_SANDPOINT is not set # CONFIG_RADSTONE_PPC7D is not set # CONFIG_ADIR is not set # CONFIG_K2 is not set # CONFIG_PAL4 is not set # CONFIG_GEMINI is not set # CONFIG_EST8260 is not set # CONFIG_SBC82xx is not set # CONFIG_SBS8260 is not set # CONFIG_RPX8260 is not set # CONFIG_TQM8260 is not set # CONFIG_ADS8272 is not set # CONFIG_PQ2FADS is not set # CONFIG_LITE5200 is not set # CONFIG_MPC834x_SYS is not set CONFIG_PPC_CHRP=y CONFIG_PPC_PMAC=y CONFIG_PPC_PREP=y CONFIG_PPC_OF=y CONFIG_PPCBUG_NVRAM=y # CONFIG_SMP is not set CONFIG_PREEMPT=y # CONFIG_HIGHMEM is not set CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PROC_DEVICETREE=y CONFIG_PREP_RESIDUAL=y CONFIG_PROC_PREPRESIDUAL=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE=console=ttyS0,9600 console=tty0 root=/dev/sda2 # CONFIG_PM_DEBUG is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION= CONFIG_SECCOMP=y CONFIG_ISA_DMA_API=y # # Bus options # # CONFIG_ISA is not set CONFIG_GENERIC_ISA_DMA=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y
Re: Hangcheck problem
On Wed, Mar 30, 2005 at 02:29:45PM -0800, Noah Silverman wrote: > On Wed, 30 Mar 2005, Noah Silverman wrote: > > I'm been experiencing a weird problem > > > > I get endlessly repeated hangcheck errors in my syslog with no > explanation: > > > > Mar 30 12:41:43 db kernel: Hangcheck: hangcheck value past margin! > Burton Windle wrote: > > Kernel version? > > > > 2.6.7 That's a really old kernel, and I'm sure anyone who could look into this will ask you to upgrade to something recent and reproduce it as the first step in tracking it down. Is this an older box? I've seen the hangcheck warnings on a 486 I was using as a firewall/router -- ultimately I applied a patch to set HZ to 100 and the problem went away. I *think*, once that patch bitrotted, that I just turned off the hangcheck timer, but I can't remember for sure. If you turn off the hangcheck timer, does the problem go away (i.e. no more lockups)? -- Joseph Fannin [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: Hangcheck problem
On Wed, Mar 30, 2005 at 02:29:45PM -0800, Noah Silverman wrote: On Wed, 30 Mar 2005, Noah Silverman wrote: I'm been experiencing a weird problem I get endlessly repeated hangcheck errors in my syslog with no explanation: Mar 30 12:41:43 db kernel: Hangcheck: hangcheck value past margin! Burton Windle wrote: Kernel version? 2.6.7 That's a really old kernel, and I'm sure anyone who could look into this will ask you to upgrade to something recent and reproduce it as the first step in tracking it down. Is this an older box? I've seen the hangcheck warnings on a 486 I was using as a firewall/router -- ultimately I applied a patch to set HZ to 100 and the problem went away. I *think*, once that patch bitrotted, that I just turned off the hangcheck timer, but I can't remember for sure. If you turn off the hangcheck timer, does the problem go away (i.e. no more lockups)? -- Joseph Fannin [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-rc3-mm1
On Sun, Feb 06, 2005 at 09:33:44PM +1100, Benjamin Herrenschmidt wrote: > On Sun, 2005-02-06 at 11:07 +0100, Peter Osterlund wrote: > > Andrew Morton <[EMAIL PROTECTED]> writes: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm1/ > > > > It gives me a kernel panic at boot if I have CONFIG_FB_RADEON > > enabled. If I also have CONFIG_FRAMEBUFFER_CONSOLE enabled, I get this > > output: > > > > Unable to handle kernel NULL pointer dereference at virtual address > > > > ... > > PREEMPT > > ... > > EIP is a strncpy_from_user+0x33/0x47 > > ... > > Call Trace: > > getname+0x69/0xa5 > > sys_open+0x12/0xc6 > > sysenter_past_esp+0x52/0x75 > > ... > > Kernel panic - not syncing: Attempted to kill init! > > > > If I don't have CONFIG_FRAMEBUFFER_CONSOLE enabled, I get a screen > > with random junk and some blinking colored boxes, and the machine > > hangs. > > That's very strange... I don't see what in radeonfb could cause this. > Just in case, can you try commenting out the call to radeon_pm_init() in > radeon_base.c, see if it makes any difference (though I don't think so). Peter, do you maybe have CONFIG_CC_OPTIMIZE_FOR_SIZE=y? I just rebuilt -rc3-mm1 to turn that off, and an Oops in copy_to_user in the i810 DRM module went away. That could have just been that it forced a rebuild with a cold ccache, I guess. The completely unrelated Oops in radeonfb I was seeing is gone now, and it works fine here (BTW). -- Joseph Fannin [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-rc3-mm1
On Sun, Feb 06, 2005 at 09:33:44PM +1100, Benjamin Herrenschmidt wrote: On Sun, 2005-02-06 at 11:07 +0100, Peter Osterlund wrote: Andrew Morton [EMAIL PROTECTED] writes: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm1/ It gives me a kernel panic at boot if I have CONFIG_FB_RADEON enabled. If I also have CONFIG_FRAMEBUFFER_CONSOLE enabled, I get this output: Unable to handle kernel NULL pointer dereference at virtual address ... PREEMPT ... EIP is a strncpy_from_user+0x33/0x47 ... Call Trace: getname+0x69/0xa5 sys_open+0x12/0xc6 sysenter_past_esp+0x52/0x75 ... Kernel panic - not syncing: Attempted to kill init! If I don't have CONFIG_FRAMEBUFFER_CONSOLE enabled, I get a screen with random junk and some blinking colored boxes, and the machine hangs. That's very strange... I don't see what in radeonfb could cause this. Just in case, can you try commenting out the call to radeon_pm_init() in radeon_base.c, see if it makes any difference (though I don't think so). Peter, do you maybe have CONFIG_CC_OPTIMIZE_FOR_SIZE=y? I just rebuilt -rc3-mm1 to turn that off, and an Oops in copy_to_user in the i810 DRM module went away. That could have just been that it forced a rebuild with a cold ccache, I guess. The completely unrelated Oops in radeonfb I was seeing is gone now, and it works fine here (BTW). -- Joseph Fannin [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: Fw: Re: 2.6.11-rc2-mm2
On Tue, Feb 01, 2005 at 10:18:33AM +1100, Benjamin Herrenschmidt wrote: > On Mon, 2005-01-31 at 06:21 -0500, Joseph Fannin wrote: > > > I'm getting a blank screen with radeonfb on two boxes here as > > well. One is a beige g3, the other is i386; both have PCI Radeon 7000s > > with radeonfb non-modular. > > > > On the PC I could see the earliest kernel messages in VGA text > > mode before radeonfb took over and the screen went blank -- no > > penguin, and the logo is enabled. Booting with radeonfb:off seemed to > > work except for the module problem in -rc2-mm2: > > > > On the ppc box I tried both -rc2-mm1 and -rc2-mm2. Both hung and > > then rebooted after 3 minutes, so it seems to be panicing somewhere. > > I backed the massive-radeonfb patch out of -mm2 and radeonfb worked, > > so I got as far as the module thing again. > > Hrm... indeed, there seem to be a problem, though I can't tell for sure > what's up now, it just works on all the configs I had a chance to test > on. Can you try to boot your G3 with serial console so you can see the > panic message if any ? Okay, I managed to get this Oops message on ppc, when modprobing a modular radeonfb. I got a similar backtrace on i386 too (lost it though). radeonfb_pci_register BEGIN PCI: Enabling device :00:0e.0 (0086 -> 0087) aper_base: 8800 MC_FB_LOC to: 8bff8800, MC_AGP_LOC to: 9000 radeonfb (:00:0e.0): Found 32768k of DDR 64 bits wide videoram radeonfb (:00:0e.0): mapped 16384k videoram radeonfb: Found Open Firmware ROM Image radeonfb: Retreived PLL infos from Open Firmware radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=183.00 Mhz, System=183.00 MHz radeonfb: PLL min 12000 max 35000 Starting monitor auto detection... radeonfb: I2C (port 1) ... not found radeonfb: I2C (port 2) ... found CRT display radeonfb: I2C (port 3) ... found CRT display radeonfb: I2C (port 4) ... not found radeon_probe_OF_head head: ATY,RV100ad_A (letter: A, head_no: 0) analyzing OF properties... display-type: CRT radeon_probe_OF_head head: ATY,RV100ad_A (letter: A, head_no: 1) radeonfb: I2C (port 3) ... found CRT display radeonfb: Monitor 1 type CRT found radeonfb: EDID probed radeonfb: Monitor 2 type CRT found radeonfb: EDID probed Oops: kernel access of bad area, sig: 11 [#1] PREEMPT NIP: C00F3DD8 LR: DD2AEF48 SP: D8C8BB50 REGS: d8c8baa0 TRAP: 0300Not tainted MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: 0008, DSISR: 4000 TASK = c040f1e0[4326] 'modprobe' THREAD: d8c8a000 Last syscall: 128 GPR00: DD2B1950 D8C8BB50 C040F1E0 D8C8BB90 D8C8BC2C DD480008 GPR08: DD2B C00F3DD8 24004482 1001E294 100013C4 GPR16: 100013C4 C032 DD2B GPR24: C032 D8C8BBD4 DD2B6470 DD2B647C D8C8BB90 DD2B6438 C08C1000 D8DBA000 NIP [c00f3dd8] fb_videomode_to_var+0x0/0x5c LR [dd2aef48] display_to_var+0x2c/0xb4 [fbcon] Call trace: [dd2b1950] fbcon_switch+0x17c/0x4d8 [fbcon] [c0124f20] redraw_screen+0x13c/0x1e8 [c01288c0] take_over_console+0x400/0x518 [dd2ae3e4] fbcon_takeover+0x98/0xfc [fbcon] [dd2b31cc] fbcon_fb_registered+0x68/0xc4 [fbcon] [dd2b3348] fbcon_event_notify+0x6c/0xd8 [fbcon] [c002bbc0] notifier_call_chain+0x40/0x68 [c00f0ec0] register_framebuffer+0x180/0x198 [dd32e834] radeonfb_pci_register+0x3bc/0x4f0 [radeonfb] [c00e9990] pci_device_probe_static+0x54/0x84 [c00e99f8] __pci_device_probe+0x38/0x6c [c00e9a5c] pci_device_probe+0x30/0x5c [c0137464] driver_probe_device+0x60/0x9c [c01375d4] driver_attach+0x58/0xbc [c0137be4] bus_add_driver+0xb0/0x108 -- Joseph Fannin [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Fw: Re: 2.6.11-rc2-mm2
On Tue, Feb 01, 2005 at 10:18:33AM +1100, Benjamin Herrenschmidt wrote: On Mon, 2005-01-31 at 06:21 -0500, Joseph Fannin wrote: I'm getting a blank screen with radeonfb on two boxes here as well. One is a beige g3, the other is i386; both have PCI Radeon 7000s with radeonfb non-modular. On the PC I could see the earliest kernel messages in VGA text mode before radeonfb took over and the screen went blank -- no penguin, and the logo is enabled. Booting with radeonfb:off seemed to work except for the module problem in -rc2-mm2: On the ppc box I tried both -rc2-mm1 and -rc2-mm2. Both hung and then rebooted after 3 minutes, so it seems to be panicing somewhere. I backed the massive-radeonfb patch out of -mm2 and radeonfb worked, so I got as far as the module thing again. Hrm... indeed, there seem to be a problem, though I can't tell for sure what's up now, it just works on all the configs I had a chance to test on. Can you try to boot your G3 with serial console so you can see the panic message if any ? Okay, I managed to get this Oops message on ppc, when modprobing a modular radeonfb. I got a similar backtrace on i386 too (lost it though). radeonfb_pci_register BEGIN PCI: Enabling device :00:0e.0 (0086 - 0087) aper_base: 8800 MC_FB_LOC to: 8bff8800, MC_AGP_LOC to: 9000 radeonfb (:00:0e.0): Found 32768k of DDR 64 bits wide videoram radeonfb (:00:0e.0): mapped 16384k videoram radeonfb: Found Open Firmware ROM Image radeonfb: Retreived PLL infos from Open Firmware radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=183.00 Mhz, System=183.00 MHz radeonfb: PLL min 12000 max 35000 Starting monitor auto detection... radeonfb: I2C (port 1) ... not found radeonfb: I2C (port 2) ... found CRT display radeonfb: I2C (port 3) ... found CRT display radeonfb: I2C (port 4) ... not found radeon_probe_OF_head head: ATY,RV100ad_A (letter: A, head_no: 0) analyzing OF properties... display-type: CRT radeon_probe_OF_head head: ATY,RV100ad_A (letter: A, head_no: 1) radeonfb: I2C (port 3) ... found CRT display radeonfb: Monitor 1 type CRT found radeonfb: EDID probed radeonfb: Monitor 2 type CRT found radeonfb: EDID probed Oops: kernel access of bad area, sig: 11 [#1] PREEMPT NIP: C00F3DD8 LR: DD2AEF48 SP: D8C8BB50 REGS: d8c8baa0 TRAP: 0300Not tainted MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: 0008, DSISR: 4000 TASK = c040f1e0[4326] 'modprobe' THREAD: d8c8a000 Last syscall: 128 GPR00: DD2B1950 D8C8BB50 C040F1E0 D8C8BB90 D8C8BC2C DD480008 GPR08: DD2B C00F3DD8 24004482 1001E294 100013C4 GPR16: 100013C4 C032 DD2B GPR24: C032 D8C8BBD4 DD2B6470 DD2B647C D8C8BB90 DD2B6438 C08C1000 D8DBA000 NIP [c00f3dd8] fb_videomode_to_var+0x0/0x5c LR [dd2aef48] display_to_var+0x2c/0xb4 [fbcon] Call trace: [dd2b1950] fbcon_switch+0x17c/0x4d8 [fbcon] [c0124f20] redraw_screen+0x13c/0x1e8 [c01288c0] take_over_console+0x400/0x518 [dd2ae3e4] fbcon_takeover+0x98/0xfc [fbcon] [dd2b31cc] fbcon_fb_registered+0x68/0xc4 [fbcon] [dd2b3348] fbcon_event_notify+0x6c/0xd8 [fbcon] [c002bbc0] notifier_call_chain+0x40/0x68 [c00f0ec0] register_framebuffer+0x180/0x198 [dd32e834] radeonfb_pci_register+0x3bc/0x4f0 [radeonfb] [c00e9990] pci_device_probe_static+0x54/0x84 [c00e99f8] __pci_device_probe+0x38/0x6c [c00e9a5c] pci_device_probe+0x30/0x5c [c0137464] driver_probe_device+0x60/0x9c [c01375d4] driver_attach+0x58/0xbc [c0137be4] bus_add_driver+0xb0/0x108 -- Joseph Fannin [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Fw: Re: 2.6.11-rc2-mm2
On Mon, Jan 31, 2005 at 06:11:50PM +1100, Benjamin Herrenschmidt wrote: > On Sat, 2005-01-29 at 16:31 -0800, Andrew Morton wrote: > It seems -mm2 definitely has some problems regarding loading of modules, > it pretty much fails loading all of them for me with some > kobject_register errors, I haven't really found out what was up, but > then, I didn't have much time neither. > > radeonfb built-in operations seem to be ok on my PowerBook3,5 (ATI M9 > based), I'll try on a PowerBook5,4 (same as yours) tomorrow hopefully. > > Does the machine hang with the screen completely cleared ? Do you see > the penguin logo ? Did you try just using pmac_defconfig ? I'm getting a blank screen with radeonfb on two boxes here as well. One is a beige g3, the other is i386; both have PCI Radeon 7000s with radeonfb non-modular. On the PC I could see the earliest kernel messages in VGA text mode before radeonfb took over and the screen went blank -- no penguin, and the logo is enabled. Booting with radeonfb:off seemed to work except for the module problem in -rc2-mm2: On the ppc box I tried both -rc2-mm1 and -rc2-mm2. Both hung and then rebooted after 3 minutes, so it seems to be panicing somewhere. I backed the massive-radeonfb patch out of -mm2 and radeonfb worked, so I got as far as the module thing again. So yeah, it's possible that there's something in -mm1 that panics my ppc, and radeonfb is just making a blank screen, but it seems more likely that radeonfb is panicing. I tried to get netconsole working on both machines, but it didn't work out for unrelated reasons. Hopefully I'll have more time to poke at this tomorrow; maybe this is helpful somehow. -- Joseph Fannin [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-rc1-mm1
On Fri, Jan 14, 2005 at 12:23:52AM -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> waiting-10s-before-mounting-root-filesystem.patch
> retry mounting the root filesystem at boot time
With this patch, initrds seem to get 'skipped'. I think this is
probably the cause for the reports of problems with RAID too.
Just after loading the initrd (RAMDISK: Loading 5284KiB [1 disk]
into ram disk...) the kernel tries to mount the real root fs -- if the
necessary drivers are built-in, it proceeds from there; if not, not.
I'm guessing that when the initrd code calls mount_block_root() to
mount the ramdisk, this bit makes it decide to try to mount the real
root instead:
if (!ROOT_DEV) {
ROOT_DEV = name_to_dev_t(saved_root_name);
create_dev(name, ROOT_DEV, root_device_name);
}
Perhaps this should not be done until after the first attempt to
mount fails? Sorry, I haven't had nearly enough coffee today to
attempt to make a patch. :-)
--
Joseph Fannin
[EMAIL PROTECTED]
"Bull in pure form is rare; there is usually some contamination by data."
-- William Graves Perry Jr.
signature.asc
Description: Digital signature
Re: 2.6.11-rc1-mm1
On Fri, Jan 14, 2005 at 12:23:52AM -0800, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
waiting-10s-before-mounting-root-filesystem.patch
retry mounting the root filesystem at boot time
With this patch, initrds seem to get 'skipped'. I think this is
probably the cause for the reports of problems with RAID too.
Just after loading the initrd (RAMDISK: Loading 5284KiB [1 disk]
into ram disk...) the kernel tries to mount the real root fs -- if the
necessary drivers are built-in, it proceeds from there; if not, not.
I'm guessing that when the initrd code calls mount_block_root() to
mount the ramdisk, this bit makes it decide to try to mount the real
root instead:
if (!ROOT_DEV) {
ROOT_DEV = name_to_dev_t(saved_root_name);
create_dev(name, ROOT_DEV, root_device_name);
}
Perhaps this should not be done until after the first attempt to
mount fails? Sorry, I haven't had nearly enough coffee today to
attempt to make a patch. :-)
--
Joseph Fannin
[EMAIL PROTECTED]
Bull in pure form is rare; there is usually some contamination by data.
-- William Graves Perry Jr.
signature.asc
Description: Digital signature
RedHat 7.0 anaconda installer doesn't support devfs
Jeff Merkey wrote: >On Sat, Oct 07, 2000 at 12:31:05AM -0400, jeff millar wrote: >> Redhat support got back to me today and said 7.0 doesnt support >> upgrades to systems running devfs. But I thought sure than Linus >> blessed it! :-) >> Does anyone have a fix? > >Good question. I noticed this as well. I couldn't run devfs on a fresh install of RedHat 7 either; the use of labels in fstab to identify partitions seems to preclude this. Well, I *could* have hacked all the necessary scripts if I knew what they were, I guess. Is there any means of using devfs and disk/partition levels together? P.S. Sorry if this breaks the threading. -- Joseph Fannin fannin.30 *at* osu.edu ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RedHat 7.0 anaconda installer doesn't support devfs
Jeff Merkey wrote: On Sat, Oct 07, 2000 at 12:31:05AM -0400, jeff millar wrote: Redhat support got back to me today and said 7.0 doesnt support upgrades to systems running devfs. But I thought sure than Linus blessed it! :-) Does anyone have a fix? Good question. I noticed this as well. I couldn't run devfs on a fresh install of RedHat 7 either; the use of labels in fstab to identify partitions seems to preclude this. Well, I *could* have hacked all the necessary scripts if I knew what they were, I guess. Is there any means of using devfs and disk/partition levels together? P.S. Sorry if this breaks the threading. -- Joseph Fannin fannin.30 *at* osu.edu ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
