With iptables v1.6.0 and kernel version 4.18-rc7, "iptables [-t table] -L"
produces diagnostic output to the effect of not being able to find the table.
Kernel version 4.17.0 and earlier work fine.
--Bob
With iptables v1.6.0 and kernel version 4.18-rc7, "iptables [-t table] -L"
produces diagnostic output to the effect of not being able to find the table.
Kernel version 4.17.0 and earlier work fine.
--Bob
On Fri, May 18, 2018 at 07:32:59PM -0500, Bob Tracy wrote:
> Every one of the 4.17-rcX series has hung during boot at the point where
> "acpid" starts up. Beginning with -rc5, the boot actually proceeds to
> completion after an "uncomfortably" long delay.
>
&g
On Fri, May 18, 2018 at 07:32:59PM -0500, Bob Tracy wrote:
> Every one of the 4.17-rcX series has hung during boot at the point where
> "acpid" starts up. Beginning with -rc5, the boot actually proceeds to
> completion after an "uncomfortably" long delay.
>
&g
Apologies for not having more in the way of diagnostic info.
Every one of the 4.17-rcX series has hung during boot at the point where
"acpid" starts up. Beginning with -rc5, the boot actually proceeds to
completion after an "uncomfortably" long delay.
Attempting to run the X11 server results in
Apologies for not having more in the way of diagnostic info.
Every one of the 4.17-rcX series has hung during boot at the point where
"acpid" starts up. Beginning with -rc5, the boot actually proceeds to
completion after an "uncomfortably" long delay.
Attempting to run the X11 server results in
The subject question is due to trouble encountered on a DEC Alpha
getting the 4.14.0 kernel to see the machine's SCSI disks at boot time.
I'm using the standard kernel source tree, and have long made it a
practice to build-in the drivers for devices required at boot time (such
as for the video
The subject question is due to trouble encountered on a DEC Alpha
getting the 4.14.0 kernel to see the machine's SCSI disks at boot time.
I'm using the standard kernel source tree, and have long made it a
practice to build-in the drivers for devices required at boot time (such
as for the video
On Wed, Nov 22, 2017 at 10:23:25PM +0900, Tetsuo Handa wrote:
> When you hit that problem next time, please capture SysRq-t and SysRq-m output
> after logging in remotely.
>
> # dmesg -c > dmesg.txt
> # echo t > /proc/sysrq-trigger
> # echo m > /proc/sysrq-trigger
> # dmesg -c >> dmesg.txt
> #
On Wed, Nov 22, 2017 at 10:23:25PM +0900, Tetsuo Handa wrote:
> When you hit that problem next time, please capture SysRq-t and SysRq-m output
> after logging in remotely.
>
> # dmesg -c > dmesg.txt
> # echo t > /proc/sysrq-trigger
> # echo m > /proc/sysrq-trigger
> # dmesg -c >> dmesg.txt
> #
On Tue, Nov 21, 2017 at 11:12:35AM -0600, Bob Tracy wrote:
> Apologies for the lack of detail, but the subject pretty much says it
> all. Xorg works fine with 4.13, but hangs on exit with 4.14.
>
> Logging in remotely and applying the "kill -9" sledgehammer has no
> e
On Tue, Nov 21, 2017 at 11:12:35AM -0600, Bob Tracy wrote:
> Apologies for the lack of detail, but the subject pretty much says it
> all. Xorg works fine with 4.13, but hangs on exit with 4.14.
>
> Logging in remotely and applying the "kill -9" sledgehammer has no
> e
Apologies for the lack of detail, but the subject pretty much says it
all. Xorg works fine with 4.13, but hangs on exit with 4.14.
Logging in remotely and applying the "kill -9" sledgehammer has no
effect. System logs don't show anything unusual going on. Rebooting
hangs because of the
Apologies for the lack of detail, but the subject pretty much says it
all. Xorg works fine with 4.13, but hangs on exit with 4.14.
Logging in remotely and applying the "kill -9" sledgehammer has no
effect. System logs don't show anything unusual going on. Rebooting
hangs because of the
A recent pull on Linus' kernel repo triggered a "git gc --auto"
maintenance action that *finally* finished after beating my poor Alpha
PWS 433au to death for 32 hours.
Here's a snapshot of the ".git/objects/pack" directory for the repo:
total 1366084
190535 12 drwxr-xr-x 2 root root
A recent pull on Linus' kernel repo triggered a "git gc --auto"
maintenance action that *finally* finished after beating my poor Alpha
PWS 433au to death for 32 hours.
Here's a snapshot of the ".git/objects/pack" directory for the repo:
total 1366084
190535 12 drwxr-xr-x 2 root root
No idea where to begin tracking this down :-(. After approximately six
days of uptime with a 4.12.0 kernel, the DNS resolver simply quits
working. All query attempts come back with "no DNS servers can be
reached". External hosts can still query the BIND server running on
the host with the
No idea where to begin tracking this down :-(. After approximately six
days of uptime with a 4.12.0 kernel, the DNS resolver simply quits
working. All query attempts come back with "no DNS servers can be
reached". External hosts can still query the BIND server running on
the host with the
On Sun, May 21, 2017 at 10:58:48AM +0200, Christoph Hellwig wrote:
> Btw, how well is alpha working these days? It looks like there hasn't
> been any maintainer activity for about two years.
Speaking for myself, the PWS 433au I've got continues to function
admirably as my IPv6 gateway. Debian
On Sun, May 21, 2017 at 10:58:48AM +0200, Christoph Hellwig wrote:
> Btw, how well is alpha working these days? It looks like there hasn't
> been any maintainer activity for about two years.
Speaking for myself, the PWS 433au I've got continues to function
admirably as my IPv6 gateway. Debian
On Wed, Apr 12, 2017 at 07:36:36PM +1200, Michael Cree wrote:
> On Wed, Apr 12, 2017 at 07:57:52AM +0200, Helge Deller wrote:
> > On 12.04.2017 04:59, Bob Tracy wrote:
> > > Bottom line is, no kernel I've built since 4.9 can load a module. All
> > > attempts to load a
On Wed, Apr 12, 2017 at 07:36:36PM +1200, Michael Cree wrote:
> On Wed, Apr 12, 2017 at 07:57:52AM +0200, Helge Deller wrote:
> > On 12.04.2017 04:59, Bob Tracy wrote:
> > > Bottom line is, no kernel I've built since 4.9 can load a module. All
> > > attempts to load a
(Adding linux-kernel to the distribution. The issue seems to be
architecture-specific, but I'm trying to understand what broke.)
The 4.10-rc1 patch set made fairly extensive modifications to
"a/kernel/module.c" (I'm leaving the "a" there so there's no doubt I
mean the top-level "kernel/module.c"
(Adding linux-kernel to the distribution. The issue seems to be
architecture-specific, but I'm trying to understand what broke.)
The 4.10-rc1 patch set made fairly extensive modifications to
"a/kernel/module.c" (I'm leaving the "a" there so there's no doubt I
mean the top-level "kernel/module.c"
r any help in resolving this.
--Bob
On Tue, Dec 13, 2016 at 08:07:10AM -0600, Bob Tracy wrote:
> Got all the way to the end of the 4.9-final kernel build, and ran into the
> following:
>
> LD init/built-in.o
> arch/alpha/lib/lib.a(strcat.o): In function `strcat':
> (.text
r any help in resolving this.
--Bob
On Tue, Dec 13, 2016 at 08:07:10AM -0600, Bob Tracy wrote:
> Got all the way to the end of the 4.9-final kernel build, and ran into the
> following:
>
> LD init/built-in.o
> arch/alpha/lib/lib.a(strcat.o): In function `strcat':
> (.text
Got all the way to the end of the 4.9-final kernel build, and ran into the
following:
LD init/built-in.o
arch/alpha/lib/lib.a(strcat.o): In function `strcat':
(.text+0x60): relocation truncated to fit: BRADDR against symbol `__stxcpy'
defined in .text section in
Got all the way to the end of the 4.9-final kernel build, and ran into the
following:
LD init/built-in.o
arch/alpha/lib/lib.a(strcat.o): In function `strcat':
(.text+0x60): relocation truncated to fit: BRADDR against symbol `__stxcpy'
defined in .text section in
On Sun, Aug 14, 2016 at 05:03:33AM -0400, james harvey wrote:
> Use static (persistent) naming instead, /dev/disk/by-label,
> /dev/disk/by-id, /dev/disk/by-uuid, and if gpt /dev/disk/by-partlabel
> and /dev/disk/by-partuuid
The key takeaway from the above is, for the non-GPT case, userspace
On Sun, Aug 14, 2016 at 05:03:33AM -0400, james harvey wrote:
> Use static (persistent) naming instead, /dev/disk/by-label,
> /dev/disk/by-id, /dev/disk/by-uuid, and if gpt /dev/disk/by-partlabel
> and /dev/disk/by-partuuid
The key takeaway from the above is, for the non-GPT case, userspace
On Wed, Apr 20, 2016 at 01:46:13AM +0100, Maciej W. Rozycki wrote:
> I can see if I can find anything suspicious there if you send me original
> copies (i.e. those that oopsed) of arch/alpha/kernel/irq_alpha.o and
> arch/alpha/kernel/core_cia.o.
>
> > Machine has been stable since the machine
On Wed, Apr 20, 2016 at 01:46:13AM +0100, Maciej W. Rozycki wrote:
> I can see if I can find anything suspicious there if you send me original
> copies (i.e. those that oopsed) of arch/alpha/kernel/irq_alpha.o and
> arch/alpha/kernel/core_cia.o.
>
> > Machine has been stable since the machine
On Mon, Apr 18, 2016 at 09:52:43PM -0500, Bob Tracy wrote:
> 4.6.0-rc4 build complete, including suggested (by Alan Young) "Verbose
> Machine Checks" option set to level 2 by default. System rebooted, and
> now we wait... Thanks for everyone's continued patience.
W
On Mon, Apr 18, 2016 at 09:52:43PM -0500, Bob Tracy wrote:
> 4.6.0-rc4 build complete, including suggested (by Alan Young) "Verbose
> Machine Checks" option set to level 2 by default. System rebooted, and
> now we wait... Thanks for everyone's continued patience.
W
On Mon, Apr 18, 2016 at 02:47:40PM +0100, Maciej W. Rozycki wrote:
> On Mon, 18 Apr 2016, Bob Tracy wrote:
>
> > Build delayed slightly. Ran into "fs/binfmt_em86.o" build failure
> > patched by Daniel Wagner back in February (incompatible-pointer-types
> > wa
On Mon, Apr 18, 2016 at 02:47:40PM +0100, Maciej W. Rozycki wrote:
> On Mon, 18 Apr 2016, Bob Tracy wrote:
>
> > Build delayed slightly. Ran into "fs/binfmt_em86.o" build failure
> > patched by Daniel Wagner back in February (incompatible-pointer-types
> > wa
On Sun, Apr 17, 2016 at 10:58:48PM -0500, Bob Tracy wrote:
> On Mon, Apr 18, 2016 at 02:32:54AM +0100, Maciej W. Rozycki wrote:
> > I'd be tempted to run with the patch below to see what's the value of
> > `la_ptr' early on in processing (`entInt' code in entry.S looks sane to
On Sun, Apr 17, 2016 at 10:58:48PM -0500, Bob Tracy wrote:
> On Mon, Apr 18, 2016 at 02:32:54AM +0100, Maciej W. Rozycki wrote:
> > I'd be tempted to run with the patch below to see what's the value of
> > `la_ptr' early on in processing (`entInt' code in entry.S looks sane to
On Mon, Apr 18, 2016 at 02:32:54AM +0100, Maciej W. Rozycki wrote:
> I'd be tempted to run with the patch below to see what's the value of
> `la_ptr' early on in processing (`entInt' code in entry.S looks sane to
> me, doesn't touch a2). NB a rebuild doesn't have to be costly if you only
>
On Mon, Apr 18, 2016 at 02:32:54AM +0100, Maciej W. Rozycki wrote:
> I'd be tempted to run with the patch below to see what's the value of
> `la_ptr' early on in processing (`entInt' code in entry.S looks sane to
> me, doesn't touch a2). NB a rebuild doesn't have to be costly if you only
>
Apologies in advance for the "poor" quality of this bug report. No idea
how to proceed, because the issue historically has been intermittent to
non-existant for reasons unknown.
Within 24 hours of booting my Alpha (PWS 433au), I'm pretty much
guaranteed to see a "machine check" Oops which
Apologies in advance for the "poor" quality of this bug report. No idea
how to proceed, because the issue historically has been intermittent to
non-existant for reasons unknown.
Within 24 hours of booting my Alpha (PWS 433au), I'm pretty much
guaranteed to see a "machine check" Oops which
On Mon, Oct 21, 2013 at 06:40:41PM -0500, Bob Tracy wrote:
> On Mon, Oct 21, 2013 at 05:52:52PM +0200, Hannes Frederic Sowa wrote:
> > On Mon, Oct 21, 2013 at 08:18:46AM -0500, Bob Tracy wrote:
> > > Actually, a regression: the 3.11 kernel is rock-solid stable
On Mon, Oct 21, 2013 at 06:40:41PM -0500, Bob Tracy wrote:
On Mon, Oct 21, 2013 at 05:52:52PM +0200, Hannes Frederic Sowa wrote:
On Mon, Oct 21, 2013 at 08:18:46AM -0500, Bob Tracy wrote:
Actually, a regression: the 3.11 kernel is rock-solid stable on my
Alpha.
Beginning
On Mon, Oct 21, 2013 at 05:52:52PM +0200, Hannes Frederic Sowa wrote:
> On Mon, Oct 21, 2013 at 08:18:46AM -0500, Bob Tracy wrote:
> > Actually, a regression: the 3.11 kernel is rock-solid stable on my
> > Alpha.
> >
> > Beginning with 3.12.0-rc1, I can reli
Actually, a regression: the 3.11 kernel is rock-solid stable on my
Alpha.
Beginning with 3.12.0-rc1, I can reliably trigger a kernel panic by
executing the gogo6.net "gw6c" IPv6 client program. If the networking
layer is active, an "Oops" will eventually (within a day) occur regardless
of
Actually, a regression: the 3.11 kernel is rock-solid stable on my
Alpha.
Beginning with 3.12.0-rc1, I can reliably trigger a kernel panic by
executing the gogo6.net gw6c IPv6 client program. If the networking
layer is active, an Oops will eventually (within a day) occur regardless
of whether I
On Mon, Oct 21, 2013 at 05:52:52PM +0200, Hannes Frederic Sowa wrote:
On Mon, Oct 21, 2013 at 08:18:46AM -0500, Bob Tracy wrote:
Actually, a regression: the 3.11 kernel is rock-solid stable on my
Alpha.
Beginning with 3.12.0-rc1, I can reliably trigger a kernel panic by
executing
On Tue, Mar 26, 2013 at 10:16:18PM +1300, Michael Cree wrote:
> On Mon, Mar 25, 2013 at 07:13:35AM -0500, Bob Tracy wrote:
> > Getting lots of these since attempting to upgrade past 3.8.0-rc7. I
> > *don't* think it's a kernel issue at this point, because while older
> >
On Tue, Mar 26, 2013 at 10:16:18PM +1300, Michael Cree wrote:
On Mon, Mar 25, 2013 at 07:13:35AM -0500, Bob Tracy wrote:
Getting lots of these since attempting to upgrade past 3.8.0-rc7. I
*don't* think it's a kernel issue at this point, because while older
kernels (found an old 3.5.0-rc4
Getting lots of these since attempting to upgrade past 3.8.0-rc7. I
*don't* think it's a kernel issue at this point, because while older
kernels (found an old 3.5.0-rc4 setup from about a year ago in my archives)
seem to take longer to reach this point, they'll eventually die exactly the
same
Getting lots of these since attempting to upgrade past 3.8.0-rc7. I
*don't* think it's a kernel issue at this point, because while older
kernels (found an old 3.5.0-rc4 setup from about a year ago in my archives)
seem to take longer to reach this point, they'll eventually die exactly the
same
On Mon, Nov 05, 2012 at 07:53:13AM -0600, Bob Tracy wrote:
> With digital signature verification support (SIGNATURE, MPILIB) enabled
> on the Alpha platform, I get the following during the MODPOST section of
> the build:
>
> ERROR: "__udiv_qrnnd" [lib/mpi/mpi.ko] undefin
On Mon, Nov 05, 2012 at 07:53:13AM -0600, Bob Tracy wrote:
With digital signature verification support (SIGNATURE, MPILIB) enabled
on the Alpha platform, I get the following during the MODPOST section of
the build:
ERROR: __udiv_qrnnd [lib/mpi/mpi.ko] undefined!
Current compiler is gcc
gcc-4.6.3
--
--------
Bob Tracy | "Build a man a fire, he'll be warm for a day. Set
r...@frus.com | a man on fire, he'll be warm for the rest of his
| life." -- D
--
Bob Tracy | Build a man a fire, he'll be warm for a day. Set
r...@frus.com | a man on fire, he'll be warm for the rest of his
| life. -- David Burge (Iowahawk
On Thu, Aug 23, 2012 at 09:16:53AM +1200, Michael Cree wrote:
> On 23/08/2012, at 12:14 AM, Bob Tracy wrote:
> >Kernel version 3.6.0-rc2, and probably -rc1 as well. I get the
> >following compile-time error on alpha architecture:
> >
> >(...)
> > CC net/core
Kernel version 3.6.0-rc2, and probably -rc1 as well. I get the
following compile-time error on alpha architecture:
(...)
CC net/core/sock.o
net/core/sock.c:274:36: error: initializer element is not constant
net/core/sock.c:274:36: error: (near initialization for "memalloc_socks")
Kernel version 3.6.0-rc2, and probably -rc1 as well. I get the
following compile-time error on alpha architecture:
(...)
CC net/core/sock.o
net/core/sock.c:274:36: error: initializer element is not constant
net/core/sock.c:274:36: error: (near initialization for memalloc_socks)
On Thu, Aug 23, 2012 at 09:16:53AM +1200, Michael Cree wrote:
On 23/08/2012, at 12:14 AM, Bob Tracy wrote:
Kernel version 3.6.0-rc2, and probably -rc1 as well. I get the
following compile-time error on alpha architecture:
(...)
CC net/core/sock.o
net/core/sock.c:274:36: error
Ivan Kokshaysky wrote:
> On Wed, Feb 13, 2008 at 11:14:43AM -0600, Bob Tracy wrote:
> > Ivan Kokshaysky wrote:
> > > No SMP, no PRINTK_TIMESTAMPS in my case. Looks like it dies trying to
> > > to switch to vga console, but I had no time to debug this yet...
> &
Ivan Kokshaysky wrote:
> On Wed, Feb 13, 2008 at 11:14:43AM -0600, Bob Tracy wrote:
> > Ivan Kokshaysky wrote:
> > > No SMP, no PRINTK_TIMESTAMPS in my case. Looks like it dies trying to
> > > to switch to vga console, but I had no time to debug this yet...
> &
Peter Zijlstra wrote:
> Does: http://lkml.org/lkml/2008/1/28/100
>
> help?
I'll give that a try this evening or tomorrow and let you know.
--
----
Bob Tracy | "I was a beta tester for dirt. They ne
Using the radeonfb
driver (built-in, default graphics mode 80x30).
--
--------
Bob Tracy | "I was a beta tester for dirt. They never did
[EMAIL PROTECTED] | get all the bugs out."
driver (built-in, default graphics mode 80x30).
--
Bob Tracy | I was a beta tester for dirt. They never did
[EMAIL PROTECTED] | get all the bugs out. - Steve McGrew
Peter Zijlstra wrote:
Does: http://lkml.org/lkml/2008/1/28/100
help?
I'll give that a try this evening or tomorrow and let you know.
--
Bob Tracy | I was a beta tester for dirt. They never did
[EMAIL
Ivan Kokshaysky wrote:
On Wed, Feb 13, 2008 at 11:14:43AM -0600, Bob Tracy wrote:
Ivan Kokshaysky wrote:
No SMP, no PRINTK_TIMESTAMPS in my case. Looks like it dies trying to
to switch to vga console, but I had no time to debug this yet...
Same basic configuration as Ivan. Concur
Ivan Kokshaysky wrote:
On Wed, Feb 13, 2008 at 11:14:43AM -0600, Bob Tracy wrote:
Ivan Kokshaysky wrote:
No SMP, no PRINTK_TIMESTAMPS in my case. Looks like it dies trying to
to switch to vga console, but I had no time to debug this yet...
Same basic configuration as Ivan. Concur
in my future. Won't be able to spend any time with
this until at least the weekend :-(.
--
--------
Bob Tracy | "I was a beta tester for dirt. They never did
[EMAIL PROTECTED] | get all the
be able to spend any time with
this until at least the weekend :-(.
--
Bob Tracy | I was a beta tester for dirt. They never did
[EMAIL PROTECTED] | get all the bugs out. - Steve McGrew
Ivan Kokshaysky wrote:
> (...)
> (http://bugzilla.kernel.org/show_bug.cgi?id=9457).
>
> [ev6-]stxncpy.S: (...)
> strncpy.S: (...)
>
> Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
ACK. 2.6.24-rc3 working fine for me with this patch applied.
Nice work!
-
Ivan Kokshaysky wrote:
(...)
(http://bugzilla.kernel.org/show_bug.cgi?id=9457).
[ev6-]stxncpy.S: (...)
strncpy.S: (...)
Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED]
ACK. 2.6.24-rc3 working fine for me with this patch applied.
Nice work!
--Bob Tracy
[EMAIL PROTECTED
Ivan Kokshaysky wrote:
> On Sat, Dec 08, 2007 at 10:19:39PM -0600, Bob Tracy wrote:
> > I *do* have CONFIG_MAGIC_SYSRQ set. Anyone care to bet whether my
> > machine starts working again if I disable it? Sheesh...
>
> Incredible...
>
> Toggling CONFIG_MAGIC_SYS
Kay Sievers wrote:
> On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
> > Kay Sievers wrote:
> > > Is the udev daemon (still) running while it fails?
> >
> > Yes, and there's something else I forgot to mention that may be
> > significant... For the bad
Kay Sievers wrote:
On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
Kay Sievers wrote:
Is the udev daemon (still) running while it fails?
Yes, and there's something else I forgot to mention that may be
significant... For the bad case, in addition to udevd, ps -ef
shows a sh -e
Ivan Kokshaysky wrote:
On Sat, Dec 08, 2007 at 10:19:39PM -0600, Bob Tracy wrote:
I *do* have CONFIG_MAGIC_SYSRQ set. Anyone care to bet whether my
machine starts working again if I disable it? Sheesh...
Incredible...
Toggling CONFIG_MAGIC_SYSRQ works for me too, so I'm finally able
Michael Cree wrote:
> Kay Sievers wrote:
> > On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
> >> Kay Sievers wrote:
> >>> Is the udev daemon (still) running while it fails?
> >> Yes, and there's something else I forgot to mention that may be
> >&g
Michael Cree wrote:
Kay Sievers wrote:
On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
Kay Sievers wrote:
Is the udev daemon (still) running while it fails?
Yes, and there's something else I forgot to mention that may be
significant... For the bad case, in addition to udevd, ps -ef
ss doesn't exit until I reboot. If this is normal under the
circumstances, please disregard.
--
--------
Bob Tracy | "They couldn't hit an elephant at this dist- "
[EMAIL PROTECTED] | - Last wor
either.
--
--------
Bob Tracy | "They couldn't hit an elephant at this dist- "
[EMAIL PROTECTED] | - Last words of Union General John Sedgwick,
| Battle of Spotsylvania Court House
t MAKEDEV (/dev/MAKEDEV -->
/sbin/MAKEDEV) is doing. In particular, Debian MAKEDEV is looking at
/proc/devices to decide what to do, so maybe "cat /proc/devices" would
be useful to look at for the broken case.
--
-----------
k/sda/sda5/dev:8:5
/sys/block/sda/sda6/dev:8:6
/sys/block/sda/sda7/dev:8:7
Assuming /sys/block even exists for the non-working case, I'll forward
that info in a few hours when I can get home to reboot the machine.
--
B
Ingo Molnar wrote:
>
> * Bob Tracy <[EMAIL PROTECTED]> wrote:
>
> > > Current state of the source tree is the 6f37ac... version, so I'll
> > > start backing out the above diffs in related groups and continue
> > > until I've got a working kernel.
net_table },
/* NET_ECONET not used */
{ NET_SCTP, "sctp", trans_net_sctp_table },
--
Bob Tracy | "They couldn't hit an elephant at this dist- "
[EMAIL PR
Andrew Morton wrote:
> On Thu, 6 Dec 2007 23:07:08 -0600 (CST) [EMAIL PROTECTED] (Bob Tracy) wrote:
> > Andrew Morton wrote:
> > > commit 6f37ac793d6ba7b35d338f791974166f67fdd9ba
> > > Merge: 2f1f53b... d90bf5a...
> > > Author: Linus Torvalds <[EMAIL PROTEC
},
--
Bob Tracy | They couldn't hit an elephant at this dist-
[EMAIL PROTECTED] | - Last words of Union General John Sedgwick,
| Battle of Spotsylvania Court House, U.S. Civil War
Andrew Morton wrote:
On Thu, 6 Dec 2007 23:07:08 -0600 (CST) [EMAIL PROTECTED] (Bob Tracy) wrote:
Andrew Morton wrote:
commit 6f37ac793d6ba7b35d338f791974166f67fdd9ba
Merge: 2f1f53b... d90bf5a...
Author: Linus Torvalds [EMAIL PROTECTED]
Date: Wed Nov 14 18:51:48 2007 -0800
reboot. If this is normal under the
circumstances, please disregard.
--
Bob Tracy | They couldn't hit an elephant at this dist-
[EMAIL PROTECTED] | - Last words of Union General John Sedgwick
.
--
Bob Tracy | They couldn't hit an elephant at this dist-
[EMAIL PROTECTED] | - Last words of Union General John Sedgwick,
| Battle of Spotsylvania Court House, U.S. Civil War
/sda/sda6/dev:8:6
/sys/block/sda/sda7/dev:8:7
Assuming /sys/block even exists for the non-working case, I'll forward
that info in a few hours when I can get home to reboot the machine.
--
Bob Tracy | They couldn't
Ingo Molnar wrote:
* Bob Tracy [EMAIL PROTECTED] wrote:
Current state of the source tree is the 6f37ac... version, so I'll
start backing out the above diffs in related groups and continue
until I've got a working kernel. For lack of an obvious target,
I'll start
. In particular, Debian MAKEDEV is looking at
/proc/devices to decide what to do, so maybe cat /proc/devices would
be useful to look at for the broken case.
--
Bob Tracy | They couldn't hit an elephant at this dist-
[EMAIL
quot; kernel I'm running now. The build is running,
and I should have an answer for us in a few hours.
--
--------
Bob Tracy | "They couldn't hit an elephant at this dist- "
[EMAIL PROTECTED]
d I'll report back. Worst case, I'll
have to start over and write off the past four days...
Sorry about this...
--
Bob Tracy | "They couldn't hit an elephant at this dist- "
[EMAIL PROTECTED] | -
t-bisect good 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3
--
--------
Bob Tracy | "They couldn't hit an elephant at this dist- "
[EMAIL PROTECTED] | - Last words of Union General John Sedgwick,
| Battle of Spotsy
2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3
--
Bob Tracy | They couldn't hit an elephant at this dist-
[EMAIL PROTECTED] | - Last words of Union General John Sedgwick,
| Battle of Spotsylvania Court House, U.S. Civil
this...
--
Bob Tracy | They couldn't hit an elephant at this dist-
[EMAIL PROTECTED] | - Last words of Union General John Sedgwick,
| Battle of Spotsylvania Court House, U.S. Civil War
,
and I should have an answer for us in a few hours.
--
Bob Tracy | They couldn't hit an elephant at this dist-
[EMAIL PROTECTED] | - Last words of Union General John Sedgwick,
| Battle
Current progress: 11 revisions left to test. The current partial
"git bisect log" is available per Ingo's suggestion on bugzilla.
http://bugzilla.kernel.org/show_bug.cgi?id=9457
--
--------
Bob Tracy | "Th
Current progress: 11 revisions left to test. The current partial
git bisect log is available per Ingo's suggestion on bugzilla.
http://bugzilla.kernel.org/show_bug.cgi?id=9457
--
Bob Tracy | They couldn't hit
1 - 100 of 211 matches
Mail list logo
