Re: x86 instability with 2.6.1{8,9}
On Wed, Jan 31, 2007 at 04:36:30PM -0500, Chuck Ebbert wrote: > Ken Moffat wrote: > > On Mon, Jan 15, 2007 at 04:29:11PM +, Ken Moffat wrote: > > > > Bizarre - it panic'd again last Thursday while I was in X, but I > > still didn't manage to log any output. At the weekend, I had the > > bright idea of using chattr +j on the syslog to try to journal any > > data, since then it has been fine. So, it isn't down to highmem, and > > I still can't trigger it reliably, or get any trace. Tried running > > as x86_64 this morning (because cold starts on Thursdays seem > > particularly problematic, perhaps it's a time/power-supply-noise > > problem), then x86 from a cold start this afternoon. > > > > Time to hope it won't bite me too often, and move on to testing > > 2.6.20-rc6. > > > > Ken > > > Try disabling preempt. Thanks for the suggestion - any particular reason ? That box is running as 64-bit at the moment, and likely to stay that way for the rest of this week while it builds userspace, but I'm not averse to running 32-bit on it again if it serves a purpose. However, in the vain hope I can actually get it to log something, wouldn't it be more useful to continue running _with_ preempt ? I'm starting to think it might have been yet another victim of the solar flares, and the fact it was always running a 32-bit kernel could have been coincidence. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 instability with 2.6.1{8,9}
Ken Moffat wrote: > On Mon, Jan 15, 2007 at 04:29:11PM +, Ken Moffat wrote: > >> Today, I've built 2.6.19.2 without highmem (the box only has 1GB, >> dunno why I'd included that in the original config) and I will >> continue to wait patiently for either a week without problems, or >> something that I can manage to note - although I think at the moment >> that the second coming of the great prophet Zarquon is more likely. >> >> > Bizarre - it panic'd again last Thursday while I was in X, but I > still didn't manage to log any output. At the weekend, I had the > bright idea of using chattr +j on the syslog to try to journal any > data, since then it has been fine. So, it isn't down to highmem, and > I still can't trigger it reliably, or get any trace. Tried running > as x86_64 this morning (because cold starts on Thursdays seem > particularly problematic, perhaps it's a time/power-supply-noise > problem), then x86 from a cold start this afternoon. > > Time to hope it won't bite me too often, and move on to testing > 2.6.20-rc6. > > Ken > Try disabling preempt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 instability with 2.6.1{8,9}
Ken Moffat wrote: On Mon, Jan 15, 2007 at 04:29:11PM +, Ken Moffat wrote: Today, I've built 2.6.19.2 without highmem (the box only has 1GB, dunno why I'd included that in the original config) and I will continue to wait patiently for either a week without problems, or something that I can manage to note - although I think at the moment that the second coming of the great prophet Zarquon is more likely. Bizarre - it panic'd again last Thursday while I was in X, but I still didn't manage to log any output. At the weekend, I had the bright idea of using chattr +j on the syslog to try to journal any data, since then it has been fine. So, it isn't down to highmem, and I still can't trigger it reliably, or get any trace. Tried running as x86_64 this morning (because cold starts on Thursdays seem particularly problematic, perhaps it's a time/power-supply-noise problem), then x86 from a cold start this afternoon. Time to hope it won't bite me too often, and move on to testing 2.6.20-rc6. Ken Try disabling preempt. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 instability with 2.6.1{8,9}
On Wed, Jan 31, 2007 at 04:36:30PM -0500, Chuck Ebbert wrote: Ken Moffat wrote: On Mon, Jan 15, 2007 at 04:29:11PM +, Ken Moffat wrote: Bizarre - it panic'd again last Thursday while I was in X, but I still didn't manage to log any output. At the weekend, I had the bright idea of using chattr +j on the syslog to try to journal any data, since then it has been fine. So, it isn't down to highmem, and I still can't trigger it reliably, or get any trace. Tried running as x86_64 this morning (because cold starts on Thursdays seem particularly problematic, perhaps it's a time/power-supply-noise problem), then x86 from a cold start this afternoon. Time to hope it won't bite me too often, and move on to testing 2.6.20-rc6. Ken Try disabling preempt. Thanks for the suggestion - any particular reason ? That box is running as 64-bit at the moment, and likely to stay that way for the rest of this week while it builds userspace, but I'm not averse to running 32-bit on it again if it serves a purpose. However, in the vain hope I can actually get it to log something, wouldn't it be more useful to continue running _with_ preempt ? I'm starting to think it might have been yet another victim of the solar flares, and the fact it was always running a 32-bit kernel could have been coincidence. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 instability with 2.6.1{8,9}
On Mon, Jan 15, 2007 at 04:29:11PM +, Ken Moffat wrote: > > Today, I've built 2.6.19.2 without highmem (the box only has 1GB, > dunno why I'd included that in the original config) and I will > continue to wait patiently for either a week without problems, or > something that I can manage to note - although I think at the moment > that the second coming of the great prophet Zarquon is more likely. > Bizarre - it panic'd again last Thursday while I was in X, but I still didn't manage to log any output. At the weekend, I had the bright idea of using chattr +j on the syslog to try to journal any data, since then it has been fine. So, it isn't down to highmem, and I still can't trigger it reliably, or get any trace. Tried running as x86_64 this morning (because cold starts on Thursdays seem particularly problematic, perhaps it's a time/power-supply-noise problem), then x86 from a cold start this afternoon. Time to hope it won't bite me too often, and move on to testing 2.6.20-rc6. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 instability with 2.6.1{8,9}
On Mon, Jan 15, 2007 at 04:29:11PM +, Ken Moffat wrote: Today, I've built 2.6.19.2 without highmem (the box only has 1GB, dunno why I'd included that in the original config) and I will continue to wait patiently for either a week without problems, or something that I can manage to note - although I think at the moment that the second coming of the great prophet Zarquon is more likely. Bizarre - it panic'd again last Thursday while I was in X, but I still didn't manage to log any output. At the weekend, I had the bright idea of using chattr +j on the syslog to try to journal any data, since then it has been fine. So, it isn't down to highmem, and I still can't trigger it reliably, or get any trace. Tried running as x86_64 this morning (because cold starts on Thursdays seem particularly problematic, perhaps it's a time/power-supply-noise problem), then x86 from a cold start this afternoon. Time to hope it won't bite me too often, and move on to testing 2.6.20-rc6. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 instability with 2.6.1{8,9}
On Sun, Jan 07, 2007 at 02:26:41PM +, Ken Moffat wrote: > > I guess that when it does have problems, it is mostly within 30 > minutes of booting - otherwise, it can be up all day. So, for the > moment I'm hopeful that changing the config will help, but it will > be several days before I feel at all confident. > Update: it doesn't seem to relate to using/not using APIC. Last Thursday it twice failed during booting (from cold), with messages all over the screen. Again, nothing reached the logs despite my best attempts. The second time, I scrolled back to try to copy it by hand, but there were several sets of messages and I'm not sure if I'd managed to get to the first of them, or if that had dropped out. It seemed to be something to do with highmem (also noticed highmem in the screen messages the first time). I tried to copy it by hand, but it all scrolled out before I'd copied anything useful as a load of 'atkbd.c Spurious ACK on isa0060/serio' messages appeared. Today, I've built 2.6.19.2 without highmem (the box only has 1GB, dunno why I'd included that in the original config) and I will continue to wait patiently for either a week without problems, or something that I can manage to note - although I think at the moment that the second coming of the great prophet Zarquon is more likely. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 instability with 2.6.1{8,9}
On Sun, Jan 07, 2007 at 02:26:41PM +, Ken Moffat wrote: I guess that when it does have problems, it is mostly within 30 minutes of booting - otherwise, it can be up all day. So, for the moment I'm hopeful that changing the config will help, but it will be several days before I feel at all confident. Update: it doesn't seem to relate to using/not using APIC. Last Thursday it twice failed during booting (from cold), with messages all over the screen. Again, nothing reached the logs despite my best attempts. The second time, I scrolled back to try to copy it by hand, but there were several sets of messages and I'm not sure if I'd managed to get to the first of them, or if that had dropped out. It seemed to be something to do with highmem (also noticed highmem in the screen messages the first time). I tried to copy it by hand, but it all scrolled out before I'd copied anything useful as a load of 'atkbd.c Spurious ACK on isa0060/serio' messages appeared. Today, I've built 2.6.19.2 without highmem (the box only has 1GB, dunno why I'd included that in the original config) and I will continue to wait patiently for either a week without problems, or something that I can manage to note - although I think at the moment that the second coming of the great prophet Zarquon is more likely. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 instability with 2.6.1{8,9}
On Sat, Jan 06, 2007 at 02:04:59PM -0800, Randy Dunlap wrote:
> On Tue, 2 Jan 2007 19:34:59 + Ken Moffat wrote:
>
> > On Tue, Jan 02, 2007 at 01:42:32PM -0500, Len Brown wrote:
> > >
> > > You might remove and re-insert the DIMMS.
> > > Sometimes there are poor contacts if the DIMMS are not fully seated and
> > > clicked in.
> > >
> > > The real mystery is the 32 vs 64-bit thing.
> > > Are the devices configured the same way -- ie are they both in IOAPIC mode
> > > and /proc/interrupts looks the same for both modes?
> > >
> > > -Len
> >
> > Too late, I've started memtest-86+. If it seems ok after an
> > overnight run, I'll take a look at /proc/interrupts. How can I tell
> > it is in IOAPIC mode, please ? Google was not helpful for this, but
> > if it's an override, the only things on my command lines are root=
> > and video= settings.
>
> (did anyone ever answer this?)
>
> In IO-APIC mode, /proc/interrupts contains entries like these:
>
>CPU0 CPU1
> 0: 121218123 0IO-APIC-edge timer
> 1: 715259 0IO-APIC-edge i8042
> 6: 5 0IO-APIC-edge floppy
> 7: 0 0IO-APIC-edge parport0
> 9: 0 0 IO-APIC-level acpi
> 12: 10011272 0IO-APIC-edge i8042
> 14: 11561548 0IO-APIC-edge ide0
> 66:4525183 0 PCI-MSI libata
> 74: 1711 0 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb6
> 82: 4 0 IO-APIC-level ohci_hcd:usb2, ohci_hcd:usb3,
> ohci_hcd:usb4, ohci_hcd:usb5
> 98: 101326 0 PCI-MSI HDA Intel
> 106: 17747181 0 PCI-MSI eth0
> 169: 0 0 IO-APIC-level uhci_hcd:usb9
> 177: 3 0 IO-APIC-level ohci1394
> 185: 15 0 IO-APIC-level uhci_hcd:usb8, aic79xx
> 193: 427962 0 IO-APIC-level uhci_hcd:usb7, aic79xx
>
> If not in IO-APIC mode, lots of those will say "XT-PIC" instead
> of IO-APIC.
>
> > Certainly, it seems likely that the configs could be fairly
> > different in their detail.
>
>
I eventually found it ("Local APIC support on uniprocessors") in
menuconfig. In the meantime, I'd moved my 32-bit activity to a
different box (also athlon64, but a bit faster) and I had one oops
on that. At least, I assume it was an oops - the caps and scroll
LEDs flashed, but I couldn't do anything with MagicSysrq, not even
force a reboot. Ran diff on the various configs, changed to IO-APIC
plus an unrelated change to use libata for the cdrom. The faster box
_seems_ stable (used for a couple of hours, and then for a whole day)
so I'm back on the original problem machine.
Last night I reconfigured the kernel (select X86_UP_APIC, deselect
ACPI_VIDEO [ had been a module ], select ACPI_DEBUG, select PCI_MSI
(had been on in my 64-bit configs), removed some ATA/ATAPI drivers I
didn't need). I was running on the 'old' 2.6.19.1 while I built it,
and again got the flashing LEDs after the build, but nothing logged
although I was able to force a reboot with SysRq b.
I guess that when it does have problems, it is mostly within 30
minutes of booting - otherwise, it can be up all day. So, for the
moment I'm hopeful that changing the config will help, but it will
be several days before I feel at all confident.
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 instability with 2.6.1{8,9}
On Sat, Jan 06, 2007 at 02:04:59PM -0800, Randy Dunlap wrote: On Tue, 2 Jan 2007 19:34:59 + Ken Moffat wrote: On Tue, Jan 02, 2007 at 01:42:32PM -0500, Len Brown wrote: You might remove and re-insert the DIMMS. Sometimes there are poor contacts if the DIMMS are not fully seated and clicked in. The real mystery is the 32 vs 64-bit thing. Are the devices configured the same way -- ie are they both in IOAPIC mode and /proc/interrupts looks the same for both modes? -Len Too late, I've started memtest-86+. If it seems ok after an overnight run, I'll take a look at /proc/interrupts. How can I tell it is in IOAPIC mode, please ? Google was not helpful for this, but if it's an override, the only things on my command lines are root= and video= settings. (did anyone ever answer this?) In IO-APIC mode, /proc/interrupts contains entries like these: CPU0 CPU1 0: 121218123 0IO-APIC-edge timer 1: 715259 0IO-APIC-edge i8042 6: 5 0IO-APIC-edge floppy 7: 0 0IO-APIC-edge parport0 9: 0 0 IO-APIC-level acpi 12: 10011272 0IO-APIC-edge i8042 14: 11561548 0IO-APIC-edge ide0 66:4525183 0 PCI-MSI libata 74: 1711 0 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb6 82: 4 0 IO-APIC-level ohci_hcd:usb2, ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5 98: 101326 0 PCI-MSI HDA Intel 106: 17747181 0 PCI-MSI eth0 169: 0 0 IO-APIC-level uhci_hcd:usb9 177: 3 0 IO-APIC-level ohci1394 185: 15 0 IO-APIC-level uhci_hcd:usb8, aic79xx 193: 427962 0 IO-APIC-level uhci_hcd:usb7, aic79xx If not in IO-APIC mode, lots of those will say XT-PIC instead of IO-APIC. Certainly, it seems likely that the configs could be fairly different in their detail. I eventually found it (Local APIC support on uniprocessors) in menuconfig. In the meantime, I'd moved my 32-bit activity to a different box (also athlon64, but a bit faster) and I had one oops on that. At least, I assume it was an oops - the caps and scroll LEDs flashed, but I couldn't do anything with MagicSysrq, not even force a reboot. Ran diff on the various configs, changed to IO-APIC plus an unrelated change to use libata for the cdrom. The faster box _seems_ stable (used for a couple of hours, and then for a whole day) so I'm back on the original problem machine. Last night I reconfigured the kernel (select X86_UP_APIC, deselect ACPI_VIDEO [ had been a module ], select ACPI_DEBUG, select PCI_MSI (had been on in my 64-bit configs), removed some ATA/ATAPI drivers I didn't need). I was running on the 'old' 2.6.19.1 while I built it, and again got the flashing LEDs after the build, but nothing logged although I was able to force a reboot with SysRq b. I guess that when it does have problems, it is mostly within 30 minutes of booting - otherwise, it can be up all day. So, for the moment I'm hopeful that changing the config will help, but it will be several days before I feel at all confident. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 instability with 2.6.1{8,9}
On Tue, 2 Jan 2007 19:34:59 + Ken Moffat wrote: > On Tue, Jan 02, 2007 at 01:42:32PM -0500, Len Brown wrote: > > > > You might remove and re-insert the DIMMS. > > Sometimes there are poor contacts if the DIMMS are not fully seated and > > clicked in. > > > > The real mystery is the 32 vs 64-bit thing. > > Are the devices configured the same way -- ie are they both in IOAPIC mode > > and /proc/interrupts looks the same for both modes? > > > > -Len > > Too late, I've started memtest-86+. If it seems ok after an > overnight run, I'll take a look at /proc/interrupts. How can I tell > it is in IOAPIC mode, please ? Google was not helpful for this, but > if it's an override, the only things on my command lines are root= > and video= settings. (did anyone ever answer this?) In IO-APIC mode, /proc/interrupts contains entries like these: CPU0 CPU1 0: 121218123 0IO-APIC-edge timer 1: 715259 0IO-APIC-edge i8042 6: 5 0IO-APIC-edge floppy 7: 0 0IO-APIC-edge parport0 9: 0 0 IO-APIC-level acpi 12: 10011272 0IO-APIC-edge i8042 14: 11561548 0IO-APIC-edge ide0 66:4525183 0 PCI-MSI libata 74: 1711 0 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb6 82: 4 0 IO-APIC-level ohci_hcd:usb2, ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5 98: 101326 0 PCI-MSI HDA Intel 106: 17747181 0 PCI-MSI eth0 169: 0 0 IO-APIC-level uhci_hcd:usb9 177: 3 0 IO-APIC-level ohci1394 185: 15 0 IO-APIC-level uhci_hcd:usb8, aic79xx 193: 427962 0 IO-APIC-level uhci_hcd:usb7, aic79xx If not in IO-APIC mode, lots of those will say "XT-PIC" instead of IO-APIC. > Certainly, it seems likely that the configs could be fairly > different in their detail. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 instability with 2.6.1{8,9}
On Tue, 2 Jan 2007 19:34:59 + Ken Moffat wrote: On Tue, Jan 02, 2007 at 01:42:32PM -0500, Len Brown wrote: You might remove and re-insert the DIMMS. Sometimes there are poor contacts if the DIMMS are not fully seated and clicked in. The real mystery is the 32 vs 64-bit thing. Are the devices configured the same way -- ie are they both in IOAPIC mode and /proc/interrupts looks the same for both modes? -Len Too late, I've started memtest-86+. If it seems ok after an overnight run, I'll take a look at /proc/interrupts. How can I tell it is in IOAPIC mode, please ? Google was not helpful for this, but if it's an override, the only things on my command lines are root= and video= settings. (did anyone ever answer this?) In IO-APIC mode, /proc/interrupts contains entries like these: CPU0 CPU1 0: 121218123 0IO-APIC-edge timer 1: 715259 0IO-APIC-edge i8042 6: 5 0IO-APIC-edge floppy 7: 0 0IO-APIC-edge parport0 9: 0 0 IO-APIC-level acpi 12: 10011272 0IO-APIC-edge i8042 14: 11561548 0IO-APIC-edge ide0 66:4525183 0 PCI-MSI libata 74: 1711 0 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb6 82: 4 0 IO-APIC-level ohci_hcd:usb2, ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5 98: 101326 0 PCI-MSI HDA Intel 106: 17747181 0 PCI-MSI eth0 169: 0 0 IO-APIC-level uhci_hcd:usb9 177: 3 0 IO-APIC-level ohci1394 185: 15 0 IO-APIC-level uhci_hcd:usb8, aic79xx 193: 427962 0 IO-APIC-level uhci_hcd:usb7, aic79xx If not in IO-APIC mode, lots of those will say XT-PIC instead of IO-APIC. Certainly, it seems likely that the configs could be fairly different in their detail. --- ~Randy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 instability with 2.6.1{8,9}
On Tue, Jan 02, 2007 at 01:42:32PM -0500, Len Brown wrote: > > You might remove and re-insert the DIMMS. > Sometimes there are poor contacts if the DIMMS are not fully seated and > clicked in. > > The real mystery is the 32 vs 64-bit thing. > Are the devices configured the same way -- ie are they both in IOAPIC mode > and /proc/interrupts looks the same for both modes? > > -Len Too late, I've started memtest-86+. If it seems ok after an overnight run, I'll take a look at /proc/interrupts. How can I tell it is in IOAPIC mode, please ? Google was not helpful for this, but if it's an override, the only things on my command lines are root= and video= settings. Certainly, it seems likely that the configs could be fairly different in their detail. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 instability with 2.6.1{8,9}
On Tuesday 02 January 2007 13:04, Ken Moffat wrote: > On Tue, Jan 02, 2007 at 12:25:57PM -0500, Len Brown wrote: > > > it's been nothing but trouble in 32-bit mode. > > > It still works fine when I boot it in 64-bit mode. > > > > A shot in the dark at the spontaneous reset issue, but no clue on the 32 vs > > 64-bit observation... > > > > See if ACPI exports any temperature readings under > > /proc/acpi/thermal_zone/*/temperature > > and if so, keep an eye on them to see if there is an indication of a > > thermal problem. > > > > ( And if ACPI doesn't, maybe lmsensors can find something.) > > > > cheers, > > -Len > > Thanks, but there is nothing there. I never managed to get > lmsensors configured (as in 'calibrated') for the hardware I tried it > on, but I was starting to think about retrying it. But first, I'm > just about to start testing with memtest86+ in case something in the > memory has gone bad. You might remove and re-insert the DIMMS. Sometimes there are poor contacts if the DIMMS are not fully seated and clicked in. The real mystery is the 32 vs 64-bit thing. Are the devices configured the same way -- ie are they both in IOAPIC mode and /proc/interrupts looks the same for both modes? -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 instability with 2.6.1{8,9}
On Tue, Jan 02, 2007 at 12:25:57PM -0500, Len Brown wrote: > > it's been nothing but trouble in 32-bit mode. > > It still works fine when I boot it in 64-bit mode. > > A shot in the dark at the spontaneous reset issue, but no clue on the 32 vs > 64-bit observation... > > See if ACPI exports any temperature readings under > /proc/acpi/thermal_zone/*/temperature > and if so, keep an eye on them to see if there is an indication of a thermal > problem. > > ( And if ACPI doesn't, maybe lmsensors can find something.) > > cheers, > -Len Thanks, but there is nothing there. I never managed to get lmsensors configured (as in 'calibrated') for the hardware I tried it on, but I was starting to think about retrying it. But first, I'm just about to start testing with memtest86+ in case something in the memory has gone bad. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 instability with 2.6.1{8,9}
> it's been nothing but trouble in 32-bit mode. > It still works fine when I boot it in 64-bit mode. A shot in the dark at the spontaneous reset issue, but no clue on the 32 vs 64-bit observation... See if ACPI exports any temperature readings under /proc/acpi/thermal_zone/*/temperature and if so, keep an eye on them to see if there is an indication of a thermal problem. ( And if ACPI doesn't, maybe lmsensors can find something.) cheers, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 instability with 2.6.1{8,9}
it's been nothing but trouble in 32-bit mode. It still works fine when I boot it in 64-bit mode. A shot in the dark at the spontaneous reset issue, but no clue on the 32 vs 64-bit observation... See if ACPI exports any temperature readings under /proc/acpi/thermal_zone/*/temperature and if so, keep an eye on them to see if there is an indication of a thermal problem. ( And if ACPI doesn't, maybe lmsensors can find something.) cheers, -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 instability with 2.6.1{8,9}
On Tue, Jan 02, 2007 at 12:25:57PM -0500, Len Brown wrote: it's been nothing but trouble in 32-bit mode. It still works fine when I boot it in 64-bit mode. A shot in the dark at the spontaneous reset issue, but no clue on the 32 vs 64-bit observation... See if ACPI exports any temperature readings under /proc/acpi/thermal_zone/*/temperature and if so, keep an eye on them to see if there is an indication of a thermal problem. ( And if ACPI doesn't, maybe lmsensors can find something.) cheers, -Len Thanks, but there is nothing there. I never managed to get lmsensors configured (as in 'calibrated') for the hardware I tried it on, but I was starting to think about retrying it. But first, I'm just about to start testing with memtest86+ in case something in the memory has gone bad. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 instability with 2.6.1{8,9}
On Tuesday 02 January 2007 13:04, Ken Moffat wrote: On Tue, Jan 02, 2007 at 12:25:57PM -0500, Len Brown wrote: it's been nothing but trouble in 32-bit mode. It still works fine when I boot it in 64-bit mode. A shot in the dark at the spontaneous reset issue, but no clue on the 32 vs 64-bit observation... See if ACPI exports any temperature readings under /proc/acpi/thermal_zone/*/temperature and if so, keep an eye on them to see if there is an indication of a thermal problem. ( And if ACPI doesn't, maybe lmsensors can find something.) cheers, -Len Thanks, but there is nothing there. I never managed to get lmsensors configured (as in 'calibrated') for the hardware I tried it on, but I was starting to think about retrying it. But first, I'm just about to start testing with memtest86+ in case something in the memory has gone bad. You might remove and re-insert the DIMMS. Sometimes there are poor contacts if the DIMMS are not fully seated and clicked in. The real mystery is the 32 vs 64-bit thing. Are the devices configured the same way -- ie are they both in IOAPIC mode and /proc/interrupts looks the same for both modes? -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 instability with 2.6.1{8,9}
On Tue, Jan 02, 2007 at 01:42:32PM -0500, Len Brown wrote: You might remove and re-insert the DIMMS. Sometimes there are poor contacts if the DIMMS are not fully seated and clicked in. The real mystery is the 32 vs 64-bit thing. Are the devices configured the same way -- ie are they both in IOAPIC mode and /proc/interrupts looks the same for both modes? -Len Too late, I've started memtest-86+. If it seems ok after an overnight run, I'll take a look at /proc/interrupts. How can I tell it is in IOAPIC mode, please ? Google was not helpful for this, but if it's an override, the only things on my command lines are root= and video= settings. Certainly, it seems likely that the configs could be fairly different in their detail. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 instability with 2.6.1{8,9}
On Monday 01 January 2007 19:13, Ken Moffat wrote:
> On Mon, Jan 01, 2007 at 05:07:58PM +, Ken Moffat wrote:
> > On Mon, Jan 01, 2007 at 04:48:55PM +, Alistair John Strachan wrote:
> > > Obviously papering over a severe bug, but why is it necessary for you
> > > to run a 32bit kernel to test 32bit userspace? If your 64bit kernel is
> > > stable, use the IA32 emulation surely?
> >
> > My 64-bit is pure64 on this machine, so it doesn't have any
> > suitable libs or tools. Anyway, I really do need a 32-bit kernel
> > to test some linuxfromscratch build instructions.
>
> Sorry, I think last night is still interfering with my own logic
> circuits. Yes, I could use 'linux32' to change the personality as a
> work-around now that I've built the system. Mainly, I was hoping
> somebody would notice something bad in the config, but I might use
> the work-around in the meantime. Thanks for reminding me about it.
Personally when I built an embedded LFS for a customer, I wrote a dummy "arch"
and "uname" and then bootstrapped the 32bit LFS book, then built a cross
compiler with the CLFS book and built a 64bit kernel. Seemed to work okay.
However, there isn't 100% compatibility in a 64bit kernel for all syscalls, I
think one of the VFAT syscall wrappers is currently broken.
[ 5807.639755] ioctl32(war3.exe:4998): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/alistair/.wine/drive_c/Program Files/Warcraft III
Other than that, I've had no problem with running a purely 32bit userspace.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 instability with 2.6.1{8,9}
On Mon, Jan 01, 2007 at 05:07:58PM +, Ken Moffat wrote: > On Mon, Jan 01, 2007 at 04:48:55PM +, Alistair John Strachan wrote: > > > > Obviously papering over a severe bug, but why is it necessary for you to > > run a > > 32bit kernel to test 32bit userspace? If your 64bit kernel is stable, use > > the > > IA32 emulation surely? > > > My 64-bit is pure64 on this machine, so it doesn't have any > suitable libs or tools. Anyway, I really do need a 32-bit kernel > to test some linuxfromscratch build instructions. > Sorry, I think last night is still interfering with my own logic circuits. Yes, I could use 'linux32' to change the personality as a work-around now that I've built the system. Mainly, I was hoping somebody would notice something bad in the config, but I might use the work-around in the meantime. Thanks for reminding me about it. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 instability with 2.6.1{8,9}
On Mon, Jan 01, 2007 at 04:48:55PM +, Alistair John Strachan wrote: > > Obviously papering over a severe bug, but why is it necessary for you to run > a > 32bit kernel to test 32bit userspace? If your 64bit kernel is stable, use the > IA32 emulation surely? > My 64-bit is pure64 on this machine, so it doesn't have any suitable libs or tools. Anyway, I really do need a 32-bit kernel to test some linuxfromscratch build instructions. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 instability with 2.6.1{8,9}
On Monday 01 January 2007 16:01, Ken Moffat wrote: > Hi, I've been running an athlon64 in 64-bit mode without problems, > up to and incluing 2.6.19.1. A couple of weeks ago I decided to use > it for testing x86 builds, since then it's been nothing but trouble > in 32-bit mode. It still works fine when I boot it in 64-bit mode. Obviously papering over a severe bug, but why is it necessary for you to run a 32bit kernel to test 32bit userspace? If your 64bit kernel is stable, use the IA32 emulation surely? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
x86 instability with 2.6.1{8,9}
Hi, I've been running an athlon64 in 64-bit mode without problems, up to and incluing 2.6.19.1. A couple of weeks ago I decided to use it for testing x86 builds, since then it's been nothing but trouble in 32-bit mode. It still works fine when I boot it in 64-bit mode. I already had a 32-bit system on the disk, but it was somewhat old (gcc-3.4.6, udev from a long while ago, glibc-2.3.4) so I wasn't totally surprised when it started to spontaneously reboot. Eventually, I installed a recent system to build a fresh 32-bit system. Still suffered from reboots - sometimes within a few minutes of booting, sometimes it was fine for hours. Tried various versions of 2.6.18.x, eventually thought it was ok, built my new system in several stages. On Saturday it was running the fresh system under 2.6.18.6 for most of the day without problems (although admittedly the first part was from the console, and only the last 2 or 3 hours were running X). Yesterday I left it building arts, and it rebooted. It was then able to finish building much of kde, and then built 2.6.19.1. Booted into 2.6.19.1, spent several hours using the desktop and running compiles and tests. Today, in 2.6.19.1, the keyboard LEDs for caps and scroll lock started flashing about 30 minutes after I'd booted it, so I guess it had oopsed. Unfortunately, nothing from the oops made it to the logs, although SysRq+b worked, so I guess I need to look at the SysRq options before it happens again. So, at the moment I've still got nothing in the logs from any of this, and it isn't predictable. This all happens while running X (originally 6.8.2, now 7.1). I'm beginning to despair of getting any indications about what is going wrong. Any suggestions, please ? Current ver_linux and config follow. Ken If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux bluesbreaker 2.6.19.1 #1 PREEMPT Sun Dec 31 17:44:47 GMT 2006 i686 athlon-4 i386 GNU/Linux Gnu C 4.1.1 Gnu make 3.81 binutils 2.17 util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.39 Linux C Library> libc.2.5 Dynamic linker (ldd) 2.5 Linux C++ Library 6.0.8 Procps 3.2.7 Kbd1.12 Sh-utils 6.6 udev 103 Modules Loaded snd_via82xx snd_mpu401_uart r8169 snd_rawmidi # # Automatically generated make config: don't edit # Linux kernel version: 2.6.19.1 # Sun Dec 31 17:37:29 2006 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODULE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set #
x86 instability with 2.6.1{8,9}
Hi, I've been running an athlon64 in 64-bit mode without problems, up to and incluing 2.6.19.1. A couple of weeks ago I decided to use it for testing x86 builds, since then it's been nothing but trouble in 32-bit mode. It still works fine when I boot it in 64-bit mode. I already had a 32-bit system on the disk, but it was somewhat old (gcc-3.4.6, udev from a long while ago, glibc-2.3.4) so I wasn't totally surprised when it started to spontaneously reboot. Eventually, I installed a recent system to build a fresh 32-bit system. Still suffered from reboots - sometimes within a few minutes of booting, sometimes it was fine for hours. Tried various versions of 2.6.18.x, eventually thought it was ok, built my new system in several stages. On Saturday it was running the fresh system under 2.6.18.6 for most of the day without problems (although admittedly the first part was from the console, and only the last 2 or 3 hours were running X). Yesterday I left it building arts, and it rebooted. It was then able to finish building much of kde, and then built 2.6.19.1. Booted into 2.6.19.1, spent several hours using the desktop and running compiles and tests. Today, in 2.6.19.1, the keyboard LEDs for caps and scroll lock started flashing about 30 minutes after I'd booted it, so I guess it had oopsed. Unfortunately, nothing from the oops made it to the logs, although SysRq+b worked, so I guess I need to look at the SysRq options before it happens again. So, at the moment I've still got nothing in the logs from any of this, and it isn't predictable. This all happens while running X (originally 6.8.2, now 7.1). I'm beginning to despair of getting any indications about what is going wrong. Any suggestions, please ? Current ver_linux and config follow. Ken If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux bluesbreaker 2.6.19.1 #1 PREEMPT Sun Dec 31 17:44:47 GMT 2006 i686 athlon-4 i386 GNU/Linux Gnu C 4.1.1 Gnu make 3.81 binutils 2.17 util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.39 Linux C Library libc.2.5 Dynamic linker (ldd) 2.5 Linux C++ Library 6.0.8 Procps 3.2.7 Kbd1.12 Sh-utils 6.6 udev 103 Modules Loaded snd_via82xx snd_mpu401_uart r8169 snd_rawmidi # # Automatically generated make config: don't edit # Linux kernel version: 2.6.19.1 # Sun Dec 31 17:37:29 2006 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODULE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set #
Re: x86 instability with 2.6.1{8,9}
On Monday 01 January 2007 16:01, Ken Moffat wrote: Hi, I've been running an athlon64 in 64-bit mode without problems, up to and incluing 2.6.19.1. A couple of weeks ago I decided to use it for testing x86 builds, since then it's been nothing but trouble in 32-bit mode. It still works fine when I boot it in 64-bit mode. Obviously papering over a severe bug, but why is it necessary for you to run a 32bit kernel to test 32bit userspace? If your 64bit kernel is stable, use the IA32 emulation surely? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 instability with 2.6.1{8,9}
On Mon, Jan 01, 2007 at 04:48:55PM +, Alistair John Strachan wrote: Obviously papering over a severe bug, but why is it necessary for you to run a 32bit kernel to test 32bit userspace? If your 64bit kernel is stable, use the IA32 emulation surely? My 64-bit is pure64 on this machine, so it doesn't have any suitable libs or tools. Anyway, I really do need a 32-bit kernel to test some linuxfromscratch build instructions. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 instability with 2.6.1{8,9}
On Mon, Jan 01, 2007 at 05:07:58PM +, Ken Moffat wrote: On Mon, Jan 01, 2007 at 04:48:55PM +, Alistair John Strachan wrote: Obviously papering over a severe bug, but why is it necessary for you to run a 32bit kernel to test 32bit userspace? If your 64bit kernel is stable, use the IA32 emulation surely? My 64-bit is pure64 on this machine, so it doesn't have any suitable libs or tools. Anyway, I really do need a 32-bit kernel to test some linuxfromscratch build instructions. Sorry, I think last night is still interfering with my own logic circuits. Yes, I could use 'linux32' to change the personality as a work-around now that I've built the system. Mainly, I was hoping somebody would notice something bad in the config, but I might use the work-around in the meantime. Thanks for reminding me about it. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 instability with 2.6.1{8,9}
On Monday 01 January 2007 19:13, Ken Moffat wrote:
On Mon, Jan 01, 2007 at 05:07:58PM +, Ken Moffat wrote:
On Mon, Jan 01, 2007 at 04:48:55PM +, Alistair John Strachan wrote:
Obviously papering over a severe bug, but why is it necessary for you
to run a 32bit kernel to test 32bit userspace? If your 64bit kernel is
stable, use the IA32 emulation surely?
My 64-bit is pure64 on this machine, so it doesn't have any
suitable libs or tools. Anyway, I really do need a 32-bit kernel
to test some linuxfromscratch build instructions.
Sorry, I think last night is still interfering with my own logic
circuits. Yes, I could use 'linux32' to change the personality as a
work-around now that I've built the system. Mainly, I was hoping
somebody would notice something bad in the config, but I might use
the work-around in the meantime. Thanks for reminding me about it.
Personally when I built an embedded LFS for a customer, I wrote a dummy arch
and uname and then bootstrapped the 32bit LFS book, then built a cross
compiler with the CLFS book and built a 64bit kernel. Seemed to work okay.
However, there isn't 100% compatibility in a 64bit kernel for all syscalls, I
think one of the VFAT syscall wrappers is currently broken.
[ 5807.639755] ioctl32(war3.exe:4998): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/alistair/.wine/drive_c/Program Files/Warcraft III
Other than that, I've had no problem with running a purely 32bit userspace.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
