[2.5.69] kexec for 2.5.69 available

[2.5.69] kexec for 2.5.69 available

Post by Andy Pfiffe » Sat, 10 May 2003 21:10:10



Eric,

I have a patch set available for kexec for 2.5.69.  I had an unrelated
delay in posting this due to some strange behavior of late with LILO and
my ext3-mounted /boot partition (/sbin/lilo would say that it updated,
but a subsequent reboot would not include my new kernel)

The patches are available for download from OSDL's patch lifecycle
manager ( http://www.osdl.org/cgi-bin/plm/ ).

Patch stack for kexec for 2.5.69:

        kexec base for 2.5.69:
        http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=1828

        kexec hwfixes for 2.5.69:
        http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=1829

        kexec usemm change (allowed 2-way to work for me):
        http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=1830

        optional change to defconfig (sets CONFIG_KEXEC=y):
        http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=1831

The patches are also available (with matching kexec-tools-1.8) from this
link pending a crontab update:
http://www.osdl.org/archive/andyp/kexec/2.5.69/

Andrew Morton's tree now also contains kexec, and you can pick up his
patch here:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/

I'll put together another release area for a matching kexec-tools for
-mm trees (different kexec syscall number between 2.5.* and 2.5.*-mm*)
as soon as I get -mm trees built and booted on my kexec test machines.

Regards,
Andy

To All: if you try kexec, a quick reply of success or failure to

please include the output of lspci in your email.

Kexec has worked for me on these systems:

    single P3-800MHz, 640MB:
        00:00.0 Host bridge: ServerWorks CNB20LE Host Bridge (rev 06)
        00:00.1 Host bridge: ServerWorks CNB20LE Host Bridge (rev 06)
        00:01.0 VGA compatible controller: S3 Inc. Savage 4 (rev 04)
        00:09.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro
        100] (rev 08)
        00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 50)
        00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller
        00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB
        Controller (rev 04)
        01:03.0 SCSI storage controller: Adaptec AIC-7892P U160/m (rev
        02)

    dual P3-866MHz, 256MB:
        00:00.0 Host bridge: ServerWorks CNB20LE Host Bridge (rev 05)
        00:00.1 Host bridge: ServerWorks CNB20LE Host Bridge (rev 05)
        00:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro
        100] (rev 08)
        00:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro
        100] (rev 08)
        00:07.0 VGA compatible controller: ATI Technologies Inc Rage XL
        (rev 65)
        00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 4f)
        00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller
        00:0f.2 USB Controller: ServerWorks OSB4/CSB5 USB Controller
        (rev 04)
        01:05.0 SCSI storage controller: LSI Logic / Symbios Logic
        53c896 (rev 07)
        01:05.1 SCSI storage controller: LSI Logic / Symbios Logic
        53c896 (rev 07)

    dual P4-1.7GHz Xeon, 512MB:
        00:00.0 Host bridge: Intel Corp. 82850 860 (Wombat) Chipset Host
        Bridge (MCH) (rev 04)
        00:01.0 PCI bridge: Intel Corp. 82850/82860 850/860
        (Tehama/Wombat) Chipset AGP Bridge (rev 04)
        00:02.0 PCI bridge: Intel Corp. 82860 860 (Wombat) Chipset PCI
        Bridge (rev 04)
        00:1e.0 PCI bridge: Intel Corp. 82801BA/CA PCI Bridge (rev 04)
        00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev
        04)
        00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 04)
        00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub  (rev
        04)
        00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 04)
        00:1f.5 Multimedia audio controller: Intel Corp. 82801BA/BAM
        AC'97 Audio (rev 04)
        01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA
        G400 AGP (rev 85)
        02:1f.0 PCI bridge: Intel Corp. 82806AA PCI64 Hub PCI Bridge
        (rev 03)
        03:00.0 PIC: Intel Corp. 82806AA PCI64 Hub Advanced Programmable
        Interrupt Controller (rev 01)
        04:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro
        100] (rev 0c)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

[2.5.69] kexec for 2.5.69 available

Post by Christophe Saou » Sat, 10 May 2003 22:10:11


Am Fre, 2003-05-09 um 21.04 schrieb Andy Pfiffer:

Quote:> [...]
>  I had an unrelated
> delay in posting this due to some strange behavior of late with LILO and
> my ext3-mounted /boot partition (/sbin/lilo would say that it updated,
> but a subsequent reboot would not include my new kernel)

So I'm not the only one having this problem... I think I first saw this
with 2.5.68 but I'm not sure.

My boot partition is a small ext3 partition on a lvm2 volume accessed
over device-mapper (I've written a lilo patch for that, but the patch is
working and) but I don't think that has something to do with the
problem.

When syncing, unmounting and waiting some time after running lilo, the
changes sometimes seem correctly written to disk, I don't know when
exactly.

Could it be that the location of /boot/map is not written to the
partition sector of /dev/hda? Or not flushed correctly or something?

After reboot the old kernel came up again (though it was moved to
vmlinuz.old).

--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

[2.5.69] kexec for 2.5.69 available

Post by Andy Pfiffe » Sat, 10 May 2003 23:00:18



> Am Fre, 2003-05-09 um 21.04 schrieb Andy Pfiffer:

> > [...]
> >  I had an unrelated
> > delay in posting this due to some strange behavior of late with LILO and
> > my ext3-mounted /boot partition (/sbin/lilo would say that it updated,
> > but a subsequent reboot would not include my new kernel)

> So I'm not the only one having this problem... I think I first saw this
> with 2.5.68 but I'm not sure.

Well, that makes two of us for sure.

Quote:

> My boot partition is a small ext3 partition on a lvm2 volume accessed
> over device-mapper (I've written a lilo patch for that, but the patch is
> working and) but I don't think that has something to do with the
> problem.

> When syncing, unmounting and waiting some time after running lilo, the
> changes sometimes seem correctly written to disk, I don't know when
> exactly.

My /boot is an ext3 partition on an IDE disk.  My symptoms and your
symptoms match -- wait awhile, and it works okay.  If you don't wait
"long enough" the changes made in /etc/lilo.conf are not reflected in
the after running /sbin/lilo and rebooting normally.

I have been unable to reproduce this on a uniproc system with SCSI
disks.

2.5.67 seems to work in this regard as expected.

Quote:> Could it be that the location of /boot/map is not written to the
> partition sector of /dev/hda? Or not flushed correctly or something?

> After reboot the old kernel came up again (though it was moved to
> vmlinuz.old).

I don't know -- I haven't isolated it yet.

Anyone else?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

[2.5.69] kexec for 2.5.69 available

Post by Riley William » Sat, 10 May 2003 23:50:11


Hi Andy, Christophe.

 >>> I had an unrelated delay in posting this due to some strange
 >>> behavior of late with LILO and my ext3-mounted /boot partition
 >>> (/sbin/lilo would say that it updated, but a subsequent reboot
 >>> would not include my new kernel)

 >> So I'm not the only one having this problem... I think I first
 >> saw this with 2.5.68 but I'm not sure.

 > Well, that makes two of us for sure.

 >> My boot partition is a small ext3 partition on a lvm2 volume
 >> accessed over device-mapper (I've written a lilo patch for
 >> that, but the patch is working and) but I don't think that has
 >> something to do with the problem.
 >>
 >> When syncing, unmounting and waiting some time after running
 >> lilo, the changes sometimes seem correctly written to disk, I
 >> don't know when exactly.
 >
 > My /boot is an ext3 partition on an IDE disk. My symptoms and
 > your symptoms match -- wait awhile, and it works okay. If you
 > don't wait "long enough" the changes made in /etc/lilo.conf are
 > not reflected in the after running /sbin/lilo and rebooting
 > normally.

One suggestion: ext3 is a journalled version of ext2, so if you can
boot with whatever is needed to specify that the boot partition is
to be mounted as ext2 rather than ext3, you can isolate the journal
system: If the problem's still there in ext2 then the journal is
not involved, but if the problem vanishes there, it's something to
do with the journal.

I have to admit that the above sounds very much like the details
are being recorded in the journal, but the journal isn't being
played back to update the actual files.

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.478 / Virus Database: 275 - Release Date: 6-May-2003

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

[2.5.69] kexec for 2.5.69 available

Post by Joe Kort » Sun, 11 May 2003 00:50:05


Quote:> One suggestion: ext3 is a journalled version of ext2, so if you can
> boot with whatever is needed to specify that the boot partition is
> to be mounted as ext2 rather than ext3, you can isolate the journal
> system: If the problem's still there in ext2 then the journal is
> not involved, but if the problem vanishes there, it's something to
> do with the journal.

> I have to admit that the above sounds very much like the details
> are being recorded in the journal, but the journal isn't being
> played back to update the actual files.

I recall reading on lkml once that an ext3 sync(2) merely pushes volatile
data/metadata out to the journal rather than to to files themselves.

Joe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

[2.5.69] kexec for 2.5.69 available

Post by Andy Pfiffe » Sun, 11 May 2003 01:50:05



> Hi Andy, Christophe.

>  >>> I had an unrelated delay in posting this due to some strange
>  >>> behavior of late with LILO and my ext3-mounted /boot partition
>  >>> (/sbin/lilo would say that it updated, but a subsequent reboot
>  >>> would not include my new kernel)

>  >> So I'm not the only one having this problem... I think I first
>  >> saw this with 2.5.68 but I'm not sure.

>  > Well, that makes two of us for sure.

>  >> My boot partition is a small ext3 partition on a lvm2 volume
>  >> accessed over device-mapper (I've written a lilo patch for
>  >> that, but the patch is working and) but I don't think that has
>  >> something to do with the problem.

>  >> When syncing, unmounting and waiting some time after running
>  >> lilo, the changes sometimes seem correctly written to disk, I
>  >> don't know when exactly.

>  > My /boot is an ext3 partition on an IDE disk. My symptoms and
>  > your symptoms match -- wait awhile, and it works okay. If you
>  > don't wait "long enough" the changes made in /etc/lilo.conf are
>  > not reflected in the after running /sbin/lilo and rebooting
>  > normally.

> One suggestion: ext3 is a journalled version of ext2, so if you can
> boot with whatever is needed to specify that the boot partition is
> to be mounted as ext2 rather than ext3, you can isolate the journal
> system: If the problem's still there in ext2 then the journal is
> not involved, but if the problem vanishes there, it's something to
> do with the journal.

Changing the "ext3" to "ext2" in /etc/fstab and rebooting did not change
the behavior (ie, edit /etc/lilo.conf, run /sbin/lilo, reboot cleanly,
changes not there).  I did see the warning about mounting an ext3
filesystem as ext2, however.

Strange.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

[2.5.69] kexec for 2.5.69 available

Post by Andy Pfiffe » Fri, 13 Jun 2003 00:20:17


On Fri, 2003-05-09 at 13:55, Andy Pfiffer wrote:
> On Fri, 2003-05-09 at 13:04, Christophe Saout wrote:
> > Am Fre, 2003-05-09 um 21.04 schrieb Andy Pfiffer:

> > > [...]
> > >  I had an unrelated
> > > delay in posting this due to some strange behavior of late with LILO and
> > > my ext3-mounted /boot partition (/sbin/lilo would say that it updated,
> > > but a subsequent reboot would not include my new kernel)

> > So I'm not the only one having this problem... I think I first saw this
> > with 2.5.68 but I'm not sure.

> Well, that makes two of us for sure.

> > My boot partition is a small ext3 partition on a lvm2 volume accessed
> > over device-mapper (I've written a lilo patch for that, but the patch is
> > working and) but I don't think that has something to do with the
> > problem.

> > When syncing, unmounting and waiting some time after running lilo, the
> > changes sometimes seem correctly written to disk, I don't know when
> > exactly.

> My /boot is an ext3 partition on an IDE disk.  My symptoms and your
> symptoms match -- wait awhile, and it works okay.  If you don't wait
> "long enough" the changes made in /etc/lilo.conf are not reflected in
> the after running /sbin/lilo and rebooting normally.

> I have been unable to reproduce this on a uniproc system with SCSI
> disks.

> 2.5.67 seems to work in this regard as expected.

> > Could it be that the location of /boot/map is not written to the
> > partition sector of /dev/hda? Or not flushed correctly or something?

> > After reboot the old kernel came up again (though it was moved to
> > vmlinuz.old).

> I don't know -- I haven't isolated it yet.

> Anyone else?

I have taken another look at this, and can confirm the following:

1. 2.5.67 works as expected.
2. 2.5.68, 2.5.69, and 2.5.70 do not.
3. ext2 vs. ext3 for /boot: no effect (ie, .68, .69, .70 demonstrate the
problem independent of the filesystem used for /boot).

Relative to a 2.5.68 pure BK tree, the deltas from 2.5.67 to 2.5.68 are:
1.971.76.10     /* 2.5.67 */
1.1124          /* 2.5.68 */

The patch exported by BK between these 2 revs is 297K lines ( a sizeable
haystack ).  Any ideas about where I should dig for my needle first
would be welcomed...

Gory details about my hardware & software follow...

% lilo -v
LILO version 22.1, Copyright (C) 1992-1998 Werner Almesberger
Development beyond version 21 Copyright (C) 1999-2001 John Coffman
Released 31-Oct-2001 and compiled at 20:50:13 on Mar 25 2002.
MAX_IMAGES = 27

CPUs:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 1
model name      : Intel(R) Xeon(TM) CPU 1.70GHz
stepping        : 2
cpu MHz         : 1685.926
cache size      : 256 KB
physical id     : 0
siblings        : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips        : 3317.76

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 0
model name      : Intel(R) Xeon(TM) CPU 1700MHz
stepping        : 10
cpu MHz         : 1685.926
cache size      : 256 KB
physical id     : 0
siblings        : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips        : 3366.91

Two IDE hard drives (I haven't cracked the case to identify the
manufacturer):

/dev/hda:
 HDIO_GETGEO_BIG failed: Inappropriate ioctl for device

 Model=CI530L04VARE700-                        , FwRev=REO44AA5,
SerialNo=        S PXXTYH2351
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
 BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=78156288
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=yes: disabled (255)
 Drive Supports : ATA/ATAPI-5 T13 1321D revision 1 : ATA-2 ATA-3 ATA-4
ATA-5

/dev/hdb:
 HDIO_GETGEO_BIG failed: Inappropriate ioctl for device

 Model=CI530L02VARE700-                        , FwRev=REO24AA5,
SerialNo=        S PVVTFT0B17
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
 BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=39876480
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=yes: disabled (255)
 Drive Supports : ATA/ATAPI-5 T13 1321D revision 1 : ATA-2 ATA-3 ATA-4
ATA-5

The PCI hardware on this system:
00:00.0 Host bridge: Intel Corp. 82850 860 (Wombat) Chipset Host Bridge
(MCH) (rev 04)
        Subsystem: IBM: Unknown device 2531
        Flags: bus master, fast devsel, latency 0
        Memory at f0000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [a0] AGP version 2.0

00:01.0 PCI bridge: Intel Corp. 82850/82860 850/860 (Tehama/Wombat)
Chipset AGP Bridge (rev 04) (prog-if 00 [Normal decode])
        Flags: bus master, 66Mhz, fast devsel, latency 64
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
        Memory behind bridge: f6000000-f8ffffff
        Prefetchable memory behind bridge: f4000000-f5ffffff

00:02.0 PCI bridge: Intel Corp. 82860 860 (Wombat) Chipset PCI Bridge
(rev 04) (prog-if 00 [Normal decode])
        Flags: bus master, 66Mhz, fast devsel, latency 32
        Bus: primary=00, secondary=02, subordinate=03, sec-latency=0
        Memory behind bridge: fb000000-fb0fffff

00:1e.0 PCI bridge: Intel Corp. 82801BA/CA PCI Bridge (rev 04) (prog-if
00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=04, subordinate=04, sec-latency=32
        I/O behind bridge: 0000c000-0000cfff
        Memory behind bridge: f9000000-faffffff

00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 04)
        Flags: bus master, medium devsel, latency 0

00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 04) (prog-if 80
[Master])
        Subsystem: IBM: Unknown device 2442
        Flags: bus master, medium devsel, latency 0
        I/O ports at f000 [size=16]

00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub  (rev 04)
(prog-if 00 [UHCI])
        Subsystem: IBM: Unknown device 2442
        Flags: bus master, medium devsel, latency 0, IRQ 19
        I/O ports at d000 [size=32]

00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 04)
        Subsystem: IBM: Unknown device 2442
        Flags: medium devsel, IRQ 17
        I/O ports at 5000 [size=16]

00:1f.5 Multimedia audio controller: Intel Corp. 82801BA/BAM AC'97 Audio
(rev 04)
        Subsystem: IBM: Unknown device 0224
        Flags: bus master, medium devsel, latency 0, IRQ 17
        I/O ports at d800 [size=256]
        I/O ports at dc00 [size=64]

01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP
(rev 85) (prog-if 00 [VGA])
        Subsystem: Matrox Graphics, Inc. Millennium G450 Dual Head
        Flags: bus master, medium devsel, latency 64, IRQ 22
        Memory at f4000000 (32-bit, prefetchable) [size=32M]
        Memory at f6000000 (32-bit, non-prefetchable) [size=16K]
        Memory at f7000000 (32-bit, non-prefetchable) [size=8M]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
        Capabilities: [f0] AGP version 2.0

02:1f.0 PCI bridge: Intel Corp. 82806AA PCI64 Hub PCI Bridge (rev 03)
(prog-if 00 [Normal decode])
        Flags: bus master, 66Mhz, fast devsel, latency 0
        Bus: primary=02, secondary=03, subordinate=03, sec-latency=32
        Memory behind bridge: fb000000-fb0fffff

03:00.0 PIC: Intel Corp. 82806AA PCI64 Hub Advanced Programmable
Interrupt Controller (rev 01) (prog-if 20 [IO(X)-APIC])
        Subsystem: Intel Corp. 82806AA PCI64 Hub Advanced Programmable
Interrupt Controller
        Flags: bus master, fast devsel, latency 0
        Memory at fb000000 (32-bit, non-prefetchable) [size=4K]

04:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
(rev 0c)
        Subsystem: IBM: Unknown device 0207
        Flags: bus master, medium devsel, latency 32, IRQ 16
        Memory at fa020000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at c000 [size=64]
        Memory at fa000000 (32-bit, non-prefetchable) [size=128K]
        Expansion ROM at <unassigned> [disabled] [size=64K]
        Capabilities: [dc] Power Management version 2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

[2.5.69] kexec for 2.5.69 available

Post by Christophe Saou » Fri, 13 Jun 2003 01:30:14


Am Don, 2003-06-12 um 00.08 schrieb Andy Pfiffer:



> > > Am Fre, 2003-05-09 um 21.04 schrieb Andy Pfiffer:

> > > > [...]
> > > >  I had an unrelated
> > > > delay in posting this due to some strange behavior of late with LILO and
> > > > my ext3-mounted /boot partition (/sbin/lilo would say that it updated,
> > > > but a subsequent reboot would not include my new kernel)

> > > So I'm not the only one having this problem... I think I first saw this
> > > with 2.5.68 but I'm not sure.

> > Well, that makes two of us for sure.

> > > My boot partition is a small ext3 partition on a lvm2 volume accessed
> > > over device-mapper (I've written a lilo patch for that, but the patch is
> > > working and) but I don't think that has something to do with the
> > > problem.

> > > When syncing, unmounting and waiting some time after running lilo, the
> > > changes sometimes seem correctly written to disk, I don't know when
> > > exactly.

> > My /boot is an ext3 partition on an IDE disk.  My symptoms and your
> > symptoms match -- wait awhile, and it works okay.  If you don't wait
> > "long enough" the changes made in /etc/lilo.conf are not reflected in
> > the after running /sbin/lilo and rebooting normally.

> > I have been unable to reproduce this on a uniproc system with SCSI
> > disks.

> > 2.5.67 seems to work in this regard as expected.

> > > Could it be that the location of /boot/map is not written to the
> > > partition sector of /dev/hda? Or not flushed correctly or something?

> > > After reboot the old kernel came up again (though it was moved to
> > > vmlinuz.old).

> > I don't know -- I haven't isolated it yet.

> > Anyone else?

> I have taken another look at this, and can confirm the following:

> 1. 2.5.67 works as expected.
> 2. 2.5.68, 2.5.69, and 2.5.70 do not.
> 3. ext2 vs. ext3 for /boot: no effect (ie, .68, .69, .70 demonstrate the
> problem independent of the filesystem used for /boot).

I found out that flushb /dev/<boot_device> helps, syncing doesn't. Not
100% sure if that's right, because right now I'm always doing both, but
I remember having only synced before and that didn't help.

Quote:> Relative to a 2.5.68 pure BK tree, the deltas from 2.5.67 to 2.5.68 are:
> 1.971.76.10        /* 2.5.67 */
> 1.1124             /* 2.5.68 */

> The patch exported by BK between these 2 revs is 297K lines ( a sizeable
> haystack ).  Any ideas about where I should dig for my needle first
> would be welcomed...

There don't seem to be too much changes in /drivers/block or /fs, mostly
cleanups. I personally have no idea where to start, except trying out
each -bk version inbetween. Hmmm. And I'm not going to do that now...
:-/

--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

[2.5.69] kexec for 2.5.69 available

Post by Bartlomiej Zolnierkiewic » Fri, 13 Jun 2003 01:50:09


mm/msync.c:
<...>
 * MS_ASYNC does not start I/O (it used to, up to 2.5.67).
<...>

You can revert changes to mm/msync.c from 2.5.68 patch
and see whether it helps.

Regards,
--
Bartlomiej


> Am Don, 2003-06-12 um 00.08 schrieb Andy Pfiffer:


> > > > Am Fre, 2003-05-09 um 21.04 schrieb Andy Pfiffer:

> > > > > [...]
> > > > >  I had an unrelated
> > > > > delay in posting this due to some strange behavior of late with LILO and
> > > > > my ext3-mounted /boot partition (/sbin/lilo would say that it updated,
> > > > > but a subsequent reboot would not include my new kernel)

> > > > So I'm not the only one having this problem... I think I first saw this
> > > > with 2.5.68 but I'm not sure.

> > > Well, that makes two of us for sure.

> > > > My boot partition is a small ext3 partition on a lvm2 volume accessed
> > > > over device-mapper (I've written a lilo patch for that, but the patch is
> > > > working and) but I don't think that has something to do with the
> > > > problem.

> > > > When syncing, unmounting and waiting some time after running lilo, the
> > > > changes sometimes seem correctly written to disk, I don't know when
> > > > exactly.

> > > My /boot is an ext3 partition on an IDE disk.  My symptoms and your
> > > symptoms match -- wait awhile, and it works okay.  If you don't wait
> > > "long enough" the changes made in /etc/lilo.conf are not reflected in
> > > the after running /sbin/lilo and rebooting normally.

> > > I have been unable to reproduce this on a uniproc system with SCSI
> > > disks.

> > > 2.5.67 seems to work in this regard as expected.

> > > > Could it be that the location of /boot/map is not written to the
> > > > partition sector of /dev/hda? Or not flushed correctly or something?

> > > > After reboot the old kernel came up again (though it was moved to
> > > > vmlinuz.old).

> > > I don't know -- I haven't isolated it yet.

> > > Anyone else?

> > I have taken another look at this, and can confirm the following:

> > 1. 2.5.67 works as expected.
> > 2. 2.5.68, 2.5.69, and 2.5.70 do not.
> > 3. ext2 vs. ext3 for /boot: no effect (ie, .68, .69, .70 demonstrate the
> > problem independent of the filesystem used for /boot).

> I found out that flushb /dev/<boot_device> helps, syncing doesn't. Not
> 100% sure if that's right, because right now I'm always doing both, but
> I remember having only synced before and that didn't help.

> > Relative to a 2.5.68 pure BK tree, the deltas from 2.5.67 to 2.5.68 are:
> > 1.971.76.10   /* 2.5.67 */
> > 1.1124                /* 2.5.68 */

> > The patch exported by BK between these 2 revs is 297K lines ( a sizeable
> > haystack ).  Any ideas about where I should dig for my needle first
> > would be welcomed...

> There don't seem to be too much changes in /drivers/block or /fs, mostly
> cleanups. I personally have no idea where to start, except trying out
> each -bk version inbetween. Hmmm. And I'm not going to do that now...
> :-/

> --


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

[2.5.69] kexec for 2.5.69 available

Post by Andy Pfiffe » Fri, 13 Jun 2003 02:30:08



> Am Don, 2003-06-12 um 00.08 schrieb Andy Pfiffer:


> > > > Am Fre, 2003-05-09 um 21.04 schrieb Andy Pfiffer:

> > > > > [...]
> > > > >  I had an unrelated
> > > > > delay in posting this due to some strange behavior of late with LILO and
> > > > > my ext3-mounted /boot partition (/sbin/lilo would say that it updated,
> > > > > but a subsequent reboot would not include my new kernel)

> > > > So I'm not the only one having this problem... I think I first saw this
> > > > with 2.5.68 but I'm not sure.
<snip>
> > I have taken another look at this, and can confirm the following:

> > 1. 2.5.67 works as expected.
> > 2. 2.5.68, 2.5.69, and 2.5.70 do not.
> > 3. ext2 vs. ext3 for /boot: no effect (ie, .68, .69, .70 demonstrate the
> > problem independent of the filesystem used for /boot).

> I found out that flushb /dev/<boot_device> helps, syncing doesn't. Not
> 100% sure if that's right, because right now I'm always doing both, but
> I remember having only synced before and that didn't help.

<snip>

A little more digging reveals this thread from May 14, 2003:
http://marc.theaimsgroup.com/?l=linux-kernel&m=105296774516509&w=2

Applying the kludge in Adam's message:

--- linux-2.5.69/fs/block_dev.c.orig    2003-05-14 17:43:40.000000000 -0700

 int blkdev_put(struct block_device *bdev, int kind)
 {
        int ret = 0;
        struct inode *bd_inode = bdev->bd_inode;
        struct gendisk *disk = bdev->bd_disk;

        down(&bdev->bd_sem);
+
+       /* AJR start */
+       switch (kind) {
+       case BDEV_FILE:
+       case BDEV_FS:
+               sync_blockdev(bd_inode->i_bdev);
+               break;
+       }
+       /* AJR end */
+
        lock_kernel();
        if (!--bdev->bd_openers) {
                switch (kind) {
                case BDEV_FILE:
                case BDEV_FS:
                        sync_blockdev(bd_inode->i_bdev);
                        break;

made things work for me in 2.5.68.
I suspect it will make things work for .70 as well.

So now the important question: is it wrong to not sync_blockdev() until
the count drops to 0?

Andy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

[2.5.69] kexec for 2.5.69 available

Post by Andrew Morto » Fri, 13 Jun 2003 02:40:12



> So now the important question: is it wrong to not sync_blockdev() until
> the count drops to 0?

Should be OK.  The close will not sync anything if someone else has the
blockdev open (ie: there's a filesystem mounted there).

But sync() should certainly write everything out, and lilo does perform a
sync.

I'd be interested in seeing the contents of /proc/meminfo immediately after
the lilo run, see if there's any dirty memory left around.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/