2002-01-10 21:43:44

by Marcelo Tosatti

[permalink] [raw]
Subject: Linux 2.4.18pre3


Hi,

So here it goes pre3.

pre3:

- Cris arch merge (Bjorn Wesen)
- Finish PPC merge (Benjamin Herrenschmidt)
- Add Dell PowerEdge 2400 to
"use BIOS to reboot" blacklist (Arjan van de Ven)
- Avoid potential oops at module unload with
cyclades driver (Andrew Morton)
- Gracefully handle SCSI initialization
failures (Pete Zaitcev)
- USB update (Greg KH)
- Fix potential oops while ejecting ide cds (Zwane Mwaikambo)
- Unify page freeing codepaths (Benjamin LaHaise)
- Miata dma corruption workaround (Richard Henderson)
- Fix vmalloc corruption problem on machines
with virtual dcaches (Ralf Baechle)
- Reiserfs fixes (Oleg Drokin)
- DiskOnChip driver update (David Woodhouse)
- Do not inherit page locking rules across
fork/exec (Dave Anderson)
- Add DRM 4.0 for XFree 4.0 users convenience (Christoph Hellwig)
- Replace .text.lock with .subsection (Keith Owens)
- IrDA bugfixes (Jean Tourrilhes)

pre2:

- APIC LVTERR fixes (Mikael Pettersson)
- Fix ppdev ioctl oops and deadlock (Tim Waugh)
- parport fixes (Tim Waugh)
- orinoco wireless driver update (David Gibson)
- Fix oopsable race in binfmt_elf.c (Alexander Viro)
- Small sx16 driver bugfix (Heinz-Ado Arnolds)
- sbp2 deadlock fix (Andrew Morton)
- Fix JFFS2 write error handling (David Woodhouse)
- Intermezzo update (Peter J. Braam)
- Proper AGP support for Intel 830MP chipsets (Nicolas Aspert)
- Alpha fixes (Jay Estabrook)
- 53c700 SCSI driver update (James Bottomley)
- Fix coredump mmap_sem deadlock on IA64 (David Mosberger)
- 3ware driver update (Adam Radford)
- Fix elevator insertion point on failed
request merge (Jens Axboe)
- Remove bogus rpciod_tcp_dispatcher definition (David Woodhouse)
- Reiserfs fixes (Oleg Drokin)
- de4x5 endianess fixes (Kip Walker)
- ISDN CAPI cleanup (Kai Germaschewski)
- Make refill_inactive() correctly account
progress (me)

pre1:

- S390 merge (IBM)
- SuperH merge (SuperH team)
- PPC merge (Benjamin Herrenschmidt)
- PCI DMA update (David S. Miller)
- radeonfb update (Ani Joshi)
- aty128fb update (Ani Joshi)
- Add nVidia GeForce3 support to rivafb (Ani Joshi)
- Add PM support to opl3sa2 (Zwane Mwaikambo)
- Basic ethtool support for 3com, starfire
and pcmcia net drivers (Jeff Garzik)
- Add MII ethtool interface (Jeff Garzik)
- starfire,sundance,dl2k,sis900,8139{too,cp},
natsemi driver updates (Jeff Garzik)
- ufs/minix: mark inodes as bad in case of read
failure (Christoph Hellwig)
- ReiserFS fixes (Oleg Drokin)
- sonypi update (Stelian Pop)
- n_hdlc update (Paul Fulghum)
- Fix compile error on aty_base.c (Tobias Ringstrom)
- Document cpu_to_xxxx() on kernel-hacking doc (Rusty Russell)
- USB update (Greg KH)
- Fix sysctl console loglevel bug on
IA64 (and possibly other archs) (Jesper Juhl)
- Update Athlon/VIA PCI quirks (Calin A. Culianu)
- blkmtd update (Simon Evans)
- boot protocol update (makes the highest
possible initrd address available to the
bootloader) (H. Peter Anvin)
- NFS fixes (Trond Myklebust)




2002-01-10 23:09:40

by Eyal Lebedinsky

[permalink] [raw]
Subject: Re: Linux 2.4.18pre3

Marcelo Tosatti wrote:
>
> Hi,
>
> So here it goes pre3.

gcc -D__KERNEL__ -I/data2/usr/local/src/linux-2.4-pre/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=i686 -malign-functions=4 -DMODULE -DMODVERSIONS -include
/data2/usr/local/src/linux-2.4-pre/include/linux/modversions.h
-DKBUILD_BASENAME=orinoco -DEXPORT_SYMTAB -c orinoco.c
orinoco.c:291: hermes_rid.h: No such file or directory
orinoco.c:293: ieee802_11.h: No such file or directory
.....
make[3]: *** [orinoco.o] Error 1
make[3]: Leaving directory
`/data2/usr/local/src/linux-2.4-pre/drivers/net/wireless'

--
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>

2002-01-10 23:45:06

by Adrian Bunk

[permalink] [raw]
Subject: Re: Linux 2.4.18pre3

Hi Marcelo,

something changed between pre2 and pre3 that broke the booting of
non-modular kernels. After LILO's "Loading Linux" message nothing else
happens. When I enable CONFIG_MODULES my kernel boots.

cu
Adrian


2002-01-11 01:45:10

by Randy Hron

[permalink] [raw]
Subject: Re: Linux 2.4.18pre3

> something changed between pre2 and pre3 that broke the booting of
> non-modular kernels. After LILO's "Loading Linux" message nothing else
> happens. When I enable CONFIG_MODULES my kernel boots.

Maybe lilo didn't execute properly.

/usr/src/linux$ egrep 'CONFIG_MOD|=m' .config
# CONFIG_MODULES is not set

/usr/src/linux$ uname -a
Linux mountain 2.4.18-pre3 #1 Thu Jan 10 20:13:52 EST 2002 i586 unknown

--
Randy Hron

2002-01-11 05:51:34

by Keith Owens

[permalink] [raw]
Subject: Re: Linux 2.4.18pre3

On Fri, 11 Jan 2002 00:44:30 +0100 (CET),
Adrian Bunk <[email protected]> wrote:
>something changed between pre2 and pre3 that broke the booting of
>non-modular kernels. After LILO's "Loading Linux" message nothing else
>happens. When I enable CONFIG_MODULES my kernel boots.

Works for me.
# uname -a
Linux snowy 2.4.18-pre3 #2 SMP Fri Jan 11 16:34:08 EST 2002 i686 unknown
# depmod
depmod: QM_MODULES: Function not implemented
# lilo -V
LILO version 21

Time for another version of my VIDEO_CHAR debugging patch.

If a kernel hangs early in the boot process (before the console has
been initialized) then printk is no use because you never see the
output. There is a technique for using the video display to indicate
boot progress so you can localize the problem. Reporting "my kernel
hangs during boot at line nnn in routine xyz" is a lot better than "my
kernel hangs during boot".

The idea is to write characters direct to the video screen during
booting using a macro called VIDEO_CHAR. This macro takes a character
position and a single character value to be displayed. Use different
positions on the screen for different levels of code and use different
characters in one position to indicate which stage that level is up to.
For example, with the patch below, the string EAC at hang indicates
parse_options(), checksetup().

Other people have patches for early printk output and those patches
might be better for your needs. The beauty of VIDEO_CHAR is that it
does not require any registers on ix86, so it can be used in Assembler
without save/restore hassles.

The patch below is generic, except for the definition of VIDEO_CHAR
which is ix86 specific. If this patch ever becomes part of the main
kernel then VIDEO_CHAR needs to be moved to an arch specific header.
If any arch other than ix86 uses this technique, please mail
[email protected] with your definition of VIDEO_CHAR.

You can plant VIDEO_CHAR calls anywhere you like, up to the call to
mem_init(). After mem_init has done its work and memory has been
remapped, VIDEO_CHAR cannot write to video memory, it will oops.
However by then the console has been initialized so you can use printk.

Demonstration patch against 2.4.18-pre3. This only uses screen
positions 0, 1, 2. If you want to drill down into lower level
routines, just use screen positions 3 onwards. To activate the
debugging, add
#define DEBUG_VIDEO_CHAR
to the start of init/main.c. If the machine is hanging then a zero
delay is fine, if it is rebooting then you need a delay to note the
characters in the top left hand corner of the screen before it reboots.
#define VIDEO_CHAR_DELAY_COUNT 100000000
A value around your clock speed gives a delay of approx. 1 second.

Index: 18-pre3.1/init/main.c
--- 18-pre3.1/init/main.c Sat, 01 Dec 2001 11:29:21 +1100 kaos (linux-2.4/k/11_main.c 1.1.5.1.1.8.1.3.1.8 644)
+++ 18-pre3.1(w)/init/main.c Fri, 11 Jan 2002 16:46:41 +1100 kaos (linux-2.4/k/11_main.c 1.1.5.1.1.8.1.3.1.8 644)
@@ -79,6 +79,16 @@ extern int irda_device_init(void);
#error Sorry, your GCC is too old. It builds incorrect kernels.
#endif

+#ifdef DEBUG_VIDEO_CHAR
+#ifndef VIDEO_CHAR_DELAY_COUNT
+#define VIDEO_CHAR_DELAY_COUNT 0
+#endif
+/* ix86 specific */
+#define VIDEO_CHAR(c, v) { int i; *((volatile char *)(0xb8000 + 2*(c))) = (v); for (i = 0; i < VIDEO_CHAR_DELAY_COUNT; ++i) ; }
+#else
+#define VIDEO_CHAR(c, v)
+#endif
+
extern char _stext, _etext;
extern char *linux_banner;

@@ -425,12 +435,14 @@ static void __init parse_options(char *l
char *next,*quote;
int args, envs;

+ VIDEO_CHAR(1, 'A');
if (!*line)
return;
args = 0;
envs = 1; /* TERM is set to 'linux' by default */
next = line;
while ((line = next) != NULL) {
+ VIDEO_CHAR(2, 'A');
quote = strchr(line,'"');
next = strchr(line, ' ');
while (next != NULL && quote != NULL && quote < next) {
@@ -443,9 +455,11 @@ static void __init parse_options(char *l
next = strchr(next+1, ' ');
}
}
+ VIDEO_CHAR(2, 'B');
if (next != NULL)
*next++ = 0;
if (!strncmp(line,"init=",5)) {
+ VIDEO_CHAR(3, 'A');
line += 5;
execute_command = line;
/* In case LILO is going to boot us with default command line,
@@ -456,8 +470,10 @@ static void __init parse_options(char *l
args = 0;
continue;
}
+ VIDEO_CHAR(2, 'C');
if (checksetup(line))
continue;
+ VIDEO_CHAR(2, 'D');

/*
* Then check if it's an environment variable or
@@ -473,9 +489,12 @@ static void __init parse_options(char *l
if (*line)
argv_init[++args] = line;
}
+ VIDEO_CHAR(2, 'E');
}
+ VIDEO_CHAR(1, 'B');
argv_init[args+1] = NULL;
envp_init[envs+1] = NULL;
+ VIDEO_CHAR(1, 'C');
}


@@ -548,16 +567,27 @@ asmlinkage void __init start_kernel(void
* Interrupts are still disabled. Do necessary setups, then
* enable them
*/
+ VIDEO_CHAR(0, 'A');
lock_kernel();
+ VIDEO_CHAR(0, 'B');
printk(linux_banner);
+ VIDEO_CHAR(0, 'C');
setup_arch(&command_line);
+ VIDEO_CHAR(0, 'D');
printk("Kernel command line: %s\n", saved_command_line);
+ VIDEO_CHAR(0, 'E');
parse_options(command_line);
+ VIDEO_CHAR(0, 'F');
trap_init();
+ VIDEO_CHAR(0, 'G');
init_IRQ();
+ VIDEO_CHAR(0, 'H');
sched_init();
+ VIDEO_CHAR(0, 'I');
softirq_init();
+ VIDEO_CHAR(0, 'J');
time_init();
+ VIDEO_CHAR(0, 'K');

/*
* HACK ALERT! This is early. We're enabling the console before
@@ -565,8 +595,10 @@ asmlinkage void __init start_kernel(void
* this. But we do want output early, in case something goes wrong.
*/
console_init();
+ VIDEO_CHAR(0, 'L');
#ifdef CONFIG_MODULES
init_modules();
+ VIDEO_CHAR(0, 'M');
#endif
if (prof_shift) {
unsigned int size;
@@ -577,10 +609,14 @@ asmlinkage void __init start_kernel(void
size = prof_len * sizeof(unsigned int) + PAGE_SIZE-1;
prof_buffer = (unsigned int *) alloc_bootmem(size);
}
+ VIDEO_CHAR(0, 'N');

kmem_cache_init();
+ VIDEO_CHAR(0, 'O');
sti();
+ VIDEO_CHAR(0, 'P');
calibrate_delay();
+ VIDEO_CHAR(0, 'Q');
#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start && !initrd_below_start_ok &&
initrd_start < min_low_pfn << PAGE_SHIFT) {
@@ -588,6 +624,7 @@ asmlinkage void __init start_kernel(void
"disabling it.\n",initrd_start,min_low_pfn << PAGE_SHIFT);
initrd_start = 0;
}
+ VIDEO_CHAR(0, 'R');
#endif
mem_init();
kmem_cache_sizes_init();

2002-01-11 23:44:38

by Kurt Garloff

[permalink] [raw]
Subject: Re: Linux 2.4.18pre3 - miata pci dma fix

Hi Marcelo, Richard, Ivan, Jay,

On Thu, Jan 10, 2002 at 06:30:07PM -0200, Marcelo Tosatti wrote:
> pre3:
>
[...]
> - Miata dma corruption workaround (Richard Henderson)
[...]

> pre2:
[...]
> - Alpha fixes (Jay Estabrook)
[...]

To be honest, I expected to see the patch from Ivan go in.

He came up with the solution to disable scatter-gather for pci dma, after I
sent a patch which justs worked around the page boundary cross bug for
ide-dma on the miata/pyxis. Disabling SG for PCI DMA on miata is no problem,
as we can directly map a 2GB window of memory into PCI space.

A second patch also made sure it works for ISA (which also support 32bis on
pyxis), so the floppy controller is happy again.
This second patch is the only thing I see when having a quick look at the
2.4.18pre3 patch, and Ivan should be credited for it as far as I know.

Is this an oversight? Or is there seom magic bit switched which I overlooked
which switches off SG PCI DMA on pyxis?

Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, DE SCSI, Security


Attachments:
(No filename) (1.17 kB)
(No filename) (232.00 B)
Download all attachments

2002-01-11 23:54:48

by Richard Henderson

[permalink] [raw]
Subject: Re: Linux 2.4.18pre3 - miata pci dma fix

On Sat, Jan 12, 2002 at 12:44:09AM +0100, Kurt Garloff wrote:
> > - Miata dma corruption workaround (Richard Henderson)
[...]
> To be honest, I expected to see the patch from Ivan go in.

It is the patch from Ivan. Marcelo mis-attributed it.


r~

2002-01-13 11:40:56

by Adrian Bunk

[permalink] [raw]
Subject: Re: Linux 2.4.18pre3


> > something changed between pre2 and pre3 that broke the booting of
> > non-modular kernels. After LILO's "Loading Linux" message nothing else
> > happens. When I enable CONFIG_MODULES my kernel boots.
>
> Maybe lilo didn't execute properly.
>...

That's possible - whatever caused the problem I'm no longer able to
reproduce it.

Sorry for bothering you with this.

cu
Adrian



2002-01-14 03:00:16

by Erik Andersen

[permalink] [raw]
Subject: radeonfb fix

On Thu Jan 10, 2002 at 06:30:07PM -0200, Marcelo Tosatti wrote:
>
> Hi,
>
> So here it goes pre3.

Hi Marcelo,

This patch is needed to make radeonfb compile and work.
It is based on an earlier patch on the list attributed to
Ani Joshi, plus adds the needed devinit fix.

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--


Attachments:
(No filename) (410.00 B)
radeonfb.patch.bz2 (2.14 kB)
Download all attachments

2002-01-14 03:14:48

by Erik Andersen

[permalink] [raw]
Subject: Re: radeonfb fix, fixed

On Sun Jan 13, 2002 at 07:59:51PM -0700, Erik wrote:
> On Thu Jan 10, 2002 at 06:30:07PM -0200, Marcelo Tosatti wrote:
> >
> > Hi,
> >
> > So here it goes pre3.
>
> Hi Marcelo,
>
> This patch is needed to make radeonfb compile and work.
> It is based on an earlier patch on the list attributed to
> Ani Joshi, plus adds the needed devinit fix.

Oops. That patch had some crap in it. Lets try that again.

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--


Attachments:
(No filename) (547.00 B)
radeonfb.patch.bz2 (1.43 kB)
Download all attachments

2002-01-14 23:39:14

by Dave Jones

[permalink] [raw]
Subject: Re: radeonfb fix, fixed

On Sun, 13 Jan 2002, Erik Andersen wrote:

> > This patch is needed to make radeonfb compile and work.
> > It is based on an earlier patch on the list attributed to
> > Ani Joshi, plus adds the needed devinit fix.
> Oops. That patch had some crap in it. Lets try that again.

Uncompressed, that patch was just 4kb. When not too big, it's
considered acceptable (and preferred) to send them as plaintext
to the list for ease of quoting.

Patch looks ok, but this bit..

diff -urN linux/drivers/video.virgin/radeonfb.c
linux/drivers/video/radeonfb.c
--- linux/drivers/video.virgin/radeonfb.c Sun Jan 13 19:09:54 2002
+++ linux/drivers/video/radeonfb.c Sun Jan 13 19:41:00 2002
@@ -686,7 +686,7 @@
name: "radeonfb",
id_table: radeonfb_pci_table,
probe: radeonfb_pci_register,
- remove: radeonfb_pci_unregister,
+ remove: __devexit_p(radeonfb_pci_unregister),
};

Is that really needed ? Hotplugable radeons ?

Dave.

--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs

2002-01-14 23:56:14

by Jeff Garzik

[permalink] [raw]
Subject: Re: radeonfb fix, fixed

Dave Jones wrote:
>
> On Sun, 13 Jan 2002, Erik Andersen wrote:
>
> > > This patch is needed to make radeonfb compile and work.
> > > It is based on an earlier patch on the list attributed to
> > > Ani Joshi, plus adds the needed devinit fix.
> > Oops. That patch had some crap in it. Lets try that again.
>
> Uncompressed, that patch was just 4kb. When not too big, it's
> considered acceptable (and preferred) to send them as plaintext
> to the list for ease of quoting.
>
> Patch looks ok, but this bit..
>
> diff -urN linux/drivers/video.virgin/radeonfb.c
> linux/drivers/video/radeonfb.c
> --- linux/drivers/video.virgin/radeonfb.c Sun Jan 13 19:09:54 2002
> +++ linux/drivers/video/radeonfb.c Sun Jan 13 19:41:00 2002
> @@ -686,7 +686,7 @@
> name: "radeonfb",
> id_table: radeonfb_pci_table,
> probe: radeonfb_pci_register,
> - remove: radeonfb_pci_unregister,
> + remove: __devexit_p(radeonfb_pci_unregister),
> };
>
> Is that really needed ? Hotplugable radeons ?

To rant on a general topic, this wholesale converting drivers to
__devexit without much thought, to fix a simple compile error, may wind
up biting users in the ass later on. Sometimes, like in the case of
radeonfb and many other fbdev drivers, the driver is -not- able to deal
with all hotplug issues without further fixes. Fixing radeonfb as with
the above simply hides those problems...

Jeff


--
Jeff Garzik | Alternate titles for LOTR:
Building 1024 | Fast Times at Uruk-Hai
MandrakeSoft | The Took, the Elf, His Daughter and Her Lover
| Samwise Gamgee: International Hobbit of Mystery