Oliver Pitzeier wrote:
[ ... ]
> If you want to know the error:
[ ... ]
> `copy_user_page' undeclared (first use in this function)
> make[1]: *** [main.o] Error 1
> make[1]: Leaving directory `/usr/src/linux-2.5.20/init'
> make: *** [init] Error 2
I guess I found where the error comes from:
(from the 2.5.20 Changelog):
> <[email protected]>
> [PATCH] pass "page" pointer to clear_user_page()/copy_user_page()
>
> Hi Linus,
>
> Are you willing to change the interfaces of clear_user_page() and
> copy_user_page() so that they can receive the relevant page pointer as
> a separate argument? I need this on ia64 to implement the lazy-cache
> flushing scheme.
>
> I believe PPC would also benefit from this.
>
> --david
Now I believe, that Alpha also benefits from this. :o) The only thing
I have to do - I guess - is to change the defines for copy_user_page()
and clear_user_page. Adding the not used parameter >pg< should not make
any problems.
Greetz,
Oliver
Hi!
I already found a few more errors while trying to compile
2.5.20. I send you the patch as soon as I have successfully
compiled the kernel _without_ problems (hopefully today).
FYI. I do not compile very much options; The main options
I compile ('coz I need 'em and nothing more...):
SCSI: QLogic ISP
Network: DECchip Tulip (dc2114x) and Early DECchip
Tulip (dc2104x)
Character Dev.: Support for console on serial port
Filesystems: EXT3 support, no ReiserFS
Network FS: NFS (as module)
Greetz,
Oliver
> Oliver Pitzeier wrote:
> [ ... ]
>
> > If you want to know the error:
>
> [ ... ]
>
> > `copy_user_page' undeclared (first use in this function)
> > make[1]: *** [main.o] Error 1
> > make[1]: Leaving directory `/usr/src/linux-2.5.20/init'
> > make: *** [init] Error 2
>
> I guess I found where the error comes from:
>
> (from the 2.5.20 Changelog):
> > <[email protected]>
> > [PATCH] pass "page" pointer to clear_user_page()/copy_user_page()
> >
> > Hi Linus,
> >
> > Are you willing to change the interfaces of clear_user_page() and
> > copy_user_page() so that they can receive the relevant page
> pointer as
> > a separate argument? I need this on ia64 to implement the
> lazy-cache
> > flushing scheme.
> >
> > I believe PPC would also benefit from this.
> >
> > --david
>
> Now I believe, that Alpha also benefits from this. :o) The
> only thing I have to do - I guess - is to change the defines
> for copy_user_page() and clear_user_page. Adding the not used
> parameter >pg< should not make any problems.
>
> Greetz,
> Oliver
Ok. Kernel compiled, but at the startup I see this:
[ ... ]
Initializing RT netlink socket
pci: passed tb register update test
pci: passed sg loopback i/o read test
pci: passed tbia test
pci: passed pte write cache snoop test
pci: failed valid tag invalid pte reload test (mcheck; workaround
available)
pci: passed pci machine check test
Kernel bug at /usr/src/linux-2.5.20/include/linux/device.h:75
swapper(1): Kernel Bug 1
pc = [<fffffc00003dceac>] ra = [<fffffc00003dbc14>] ps = 0000 Not
tainted
v0 = 0000000000000000 t0 = 0000000000000000 t1 = fffffc00005b3a48
t2 = fffffc00001e2888 t3 = fffffc00001e2878 t4 = ffffffff00000000
t5 = 0000000000000001 t6 = fffffc000ffe1c68 t7 = fffffc00008a8000
a0 = fffffc00001e2878 a1 = 0000000000000000 a2 = 0000000000000000
a3 = 0000000000000000 a4 = fffffffffffffffe a5 = 0000000000000002
t8 = fffffc00005a85b0 t9 = 0000000000008000 t10= 0000000000008000
t11= 0000000000010000 pv = fffffc00003dce80 at = 0000000000000000
gp = fffffc00005eece8 sp = fffffc00008ab400
Trace:fffffc00003dbc14 fffffc00003100c8 fffffc0000310708
fffffc0000310bf8 fffffc000032ed58 fffffc000031008c fffffc00003100b0
fffffc00003106f0
Code: a44400c0 2fe00000 e4400018 a022000c f4200004 00000081
<0000004b> 00579a9d
Kernel panic: Attempted to kill init!
I check what is on line 75 in device.h!
Greetz,
Oliver
PS: Anybody want's the patches???
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Oliver Pitzeier
> Sent: Tuesday, June 04, 2002 2:45 PM
> To: 'Ivan Kokshaysky'
> Cc: [email protected]; [email protected]
> Subject: RE: kernel 2.5.20 on alpha (RE: [patch] Re: kernel
> 2.5.18 on alpha)
>
>
> Hi!
>
> I already found a few more errors while trying to compile
> 2.5.20. I send you the patch as soon as I have successfully
> compiled the kernel _without_ problems (hopefully today).
>
> FYI. I do not compile very much options; The main options
> I compile ('coz I need 'em and nothing more...):
> SCSI: QLogic ISP
> Network: DECchip Tulip (dc2114x) and Early DECchip
> Tulip (dc2104x)
> Character Dev.: Support for console on serial port
> Filesystems: EXT3 support, no ReiserFS
> Network FS: NFS (as module)
>
> Greetz,
> Oliver
>
> > Oliver Pitzeier wrote:
> > [ ... ]
> >
> > > If you want to know the error:
> >
> > [ ... ]
> >
> > > `copy_user_page' undeclared (first use in this function)
> > > make[1]: *** [main.o] Error 1
> > > make[1]: Leaving directory `/usr/src/linux-2.5.20/init'
> > > make: *** [init] Error 2
> >
> > I guess I found where the error comes from:
> >
> > (from the 2.5.20 Changelog):
> > > <[email protected]>
> > > [PATCH] pass "page" pointer to clear_user_page()/copy_user_page()
> > >
> > > Hi Linus,
> > >
> > > Are you willing to change the interfaces of clear_user_page() and
> > > copy_user_page() so that they can receive the relevant page
> > pointer as
> > > a separate argument? I need this on ia64 to implement the
> > lazy-cache
> > > flushing scheme.
> > >
> > > I believe PPC would also benefit from this.
> > >
> > > --david
> >
> > Now I believe, that Alpha also benefits from this. :o) The
> > only thing I have to do - I guess - is to change the defines
> > for copy_user_page() and clear_user_page. Adding the not used
> > parameter >pg< should not make any problems.
> >
> > Greetz,
> > Oliver
>
>
>
>
> _______________________________________________
> Axp-kernel-list mailing list
> [email protected]
> https://listman.redhat.com/mailman/listinfo/axp-kernel-list
>
On Tue, 2002-06-04 16:06:35 +0200, Oliver Pitzeier <[email protected]>
wrote in message <[email protected]>:
> Ok. Kernel compiled, but at the startup I see this:
> [ ... ]
> Initializing RT netlink socket
> pci: passed tb register update test
> pci: passed sg loopback i/o read test
> pci: passed tbia test
> pci: passed pte write cache snoop test
> pci: failed valid tag invalid pte reload test (mcheck; workaround
> available)
> pci: passed pci machine check test
> Kernel bug at /usr/src/linux-2.5.20/include/linux/device.h:75
> swapper(1): Kernel Bug 1
> pc = [<fffffc00003dceac>] ra = [<fffffc00003dbc14>] ps = 0000 Not
> tainted
> v0 = 0000000000000000 t0 = 0000000000000000 t1 = fffffc00005b3a48
>
> I check what is on line 75 in device.h!
That's a known problem. Please look for my mail with Subject "[2.5.19]
Oops during PCI scan on Alpha". One follow-up had a working (but
hackish) fix.
> PS: Anybody want's the patches???
/me
MfG, JBG
PS: Please answer _under_ or _within_ an old mail, but never ever above
it!
--
Jan-Benedict Glaw . [email protected] . +49-172-7608481
-- New APT-Proxy written in shell script --
http://lug-owl.de/~jbglaw/software/ap2/
Can anybody tell me what's wrong within this line:
linux-2.5.20/include/linux/device.h:
[ ... ]
73 static inline struct bus_type * get_bus(struct bus_type * bus)
74 {
-->> 75 BUG_ON(!atomic_read(&bus->refcount));
76 atomic_inc(&bus->refcount);
77 return bus;
78 }
[ ... ]
I guess BUG_ON always produces an error? But why is my kernel
jumping there and why is BUG_ON there?
This is new to me... I can't find get_bus in 2.5.18.
-Oliver
Oliver Pitzeier wrote:
> Ok. Kernel compiled, but at the startup I see this:
> [ ... ]
> Initializing RT netlink socket
> pci: passed tb register update test
> pci: passed sg loopback i/o read test
> pci: passed tbia test
> pci: passed pte write cache snoop test
> pci: failed valid tag invalid pte reload test (mcheck; workaround
> available)
> pci: passed pci machine check test
> Kernel bug at /usr/src/linux-2.5.20/include/linux/device.h:75
> swapper(1): Kernel Bug 1
> pc = [<fffffc00003dceac>] ra = [<fffffc00003dbc14>] ps = 0000 Not
> tainted
> v0 = 0000000000000000 t0 = 0000000000000000 t1 =
> fffffc00005b3a48 t2 = fffffc00001e2888 t3 = fffffc00001e2878
> t4 = ffffffff00000000 t5 = 0000000000000001 t6 =
> fffffc000ffe1c68 t7 = fffffc00008a8000 a0 = fffffc00001e2878
> a1 = 0000000000000000 a2 = 0000000000000000 a3 =
> 0000000000000000 a4 = fffffffffffffffe a5 =
> 0000000000000002 t8 = fffffc00005a85b0 t9 = 0000000000008000
> t10= 0000000000008000 t11= 0000000000010000 pv =
> fffffc00003dce80 at = 0000000000000000 gp = fffffc00005eece8
> sp = fffffc00008ab400 Trace:fffffc00003dbc14
> fffffc00003100c8 fffffc0000310708 fffffc0000310bf8
> fffffc000032ed58 fffffc000031008c fffffc00003100b0 fffffc00003106f0
> Code: a44400c0 2fe00000 e4400018 a022000c f4200004
> 00000081 <0000004b> 00579a9d
> Kernel panic: Attempted to kill init!
>
> I check what is on line 75 in device.h!
>
> Greetz,
> Oliver
>
> PS: Anybody want's the patches???
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of
> Oliver Pitzeier
> > Sent: Tuesday, June 04, 2002 2:45 PM
> > To: 'Ivan Kokshaysky'
> > Cc: [email protected]; [email protected]
> > Subject: RE: kernel 2.5.20 on alpha (RE: [patch] Re: kernel
> > 2.5.18 on alpha)
> >
> >
> > Hi!
> >
> > I already found a few more errors while trying to compile
> > 2.5.20. I send you the patch as soon as I have successfully
> > compiled the kernel _without_ problems (hopefully today).
> >
> > FYI. I do not compile very much options; The main options
> > I compile ('coz I need 'em and nothing more...):
> > SCSI: QLogic ISP
> > Network: DECchip Tulip (dc2114x) and Early DECchip
> > Tulip (dc2104x)
> > Character Dev.: Support for console on serial port
> > Filesystems: EXT3 support, no ReiserFS
> > Network FS: NFS (as module)
> >
> > Greetz,
> > Oliver
> >
> > > Oliver Pitzeier wrote:
> > > [ ... ]
> > >
> > > > If you want to know the error:
> > >
> > > [ ... ]
> > >
> > > > `copy_user_page' undeclared (first use in this function)
> > > > make[1]: *** [main.o] Error 1
> > > > make[1]: Leaving directory `/usr/src/linux-2.5.20/init'
> > > > make: *** [init] Error 2
> > >
> > > I guess I found where the error comes from:
> > >
> > > (from the 2.5.20 Changelog):
> > > > <[email protected]>
> > > > [PATCH] pass "page" pointer to
> clear_user_page()/copy_user_page()
> > > >
> > > > Hi Linus,
> > > >
> > > > Are you willing to change the interfaces of
> clear_user_page() and
> > > > copy_user_page() so that they can receive the relevant page
> > > pointer as
> > > > a separate argument? I need this on ia64 to implement the
> > > lazy-cache
> > > > flushing scheme.
> > > >
> > > > I believe PPC would also benefit from this.
> > > >
> > > > --david
> > >
> > > Now I believe, that Alpha also benefits from this. :o) The only
> > > thing I have to do - I guess - is to change the defines for
> > > copy_user_page() and clear_user_page. Adding the not used
> parameter
> > > >pg< should not make any problems.
> > >
> > > Greetz,
> > > Oliver
Jan-Benedict Glaw wrote:
> That's a known problem. Please look for my mail with Subject
> "[2.5.19] Oops during PCI scan on Alpha". One follow-up had a
> working (but
> hackish) fix.
[ ... ]
OK. Next error. I give up for today. :o)
[ ... ]
Freeing unused kernel memory: 360k freed
Kernel bug at ll_rw_blk.c:1602
swapper(1): Kernel Bug 1
pc = [<fffffc000040b850>] ra = [<fffffc000040ba44>] ps = 0000 Not
tainted
v0 = 0000000000000000 t0 = 0000000000000060 t1 = 0000000000000001
t2 = fffffc000fd84740 t3 = 0000000000000000 t4 = 0000000000000060
t5 = 0000000000000001 t6 = fffffc000fcfabf0 t7 = fffffc00008a8000
a0 = fffffc000fee08c0 a1 = fffffc000fee08c0 a2 = fffffc00008ab4e0
a3 = fffffc00008ab4f0 a4 = fffffc00008ab554 a5 = 0000000000000001
t8 = 0000000000000000 t9 = 0000000000000001 t10= 0000000000000000
t11= 0000000000000278 pv = fffffc000040b9a0 at = fffffc00005acc90
gp = fffffc00005eece8 sp = fffffc00008ab530
Trace:fffffc000040ba44 fffffc0000382e00 fffffc00003831f4
fffffc0000383354 fffffc00003b2280 fffffc00003d630c fffffc00003464ac
fffffc00003b2280 fffffc00003b280c fffffc0000359c10 fffffc0000359e14
fffffc0000347204 fffffc0000347928 fffffc00003477d0 fffffc0000368b58
fffffc0000369a00 fffffc000031078c fffffc00003101cc fffffc0000310708
fffffc0000310bf8 fffffc000032ed58 fffffc000031008c fffffc00003100b0
fffffc00003106f0
Code: 4821f621 48213681 48407622 404103a2 e4400005 00000081
<00000642> 0057c095
Kernel panic: Attempted to kill init!
[ I apologize for answering this so late, and being so tardy in releasing
docs explaining all this. I'll be sending docs to the list soon... ]
On Tue, 4 Jun 2002, Oliver Pitzeier wrote:
> Can anybody tell me what's wrong within this line:
>
> linux-2.5.20/include/linux/device.h:
> [ ... ]
> 73 static inline struct bus_type * get_bus(struct bus_type * bus)
> 74 {
> -->> 75 BUG_ON(!atomic_read(&bus->refcount));
> 76 atomic_inc(&bus->refcount);
> 77 return bus;
> 78 }
> [ ... ]
>
> I guess BUG_ON always produces an error? But why is my kernel
> jumping there and why is BUG_ON there?
The short of it: 2.5.19 introduced a struct bus_type that describes each
bus type in the system. It holds lists of all the devices and drivers that
are found for that bus type.
When a bus is probed and devices are discovered, they are inserted into
the bus's list of devices (as well as their place in the global
hierarchy).
The problem: bus_types are registered with the system, which intializes
all the internal fields, making them ready for use. The PCI bus is being
probed before the PCI bus type has been registered.
device_register() calls bus_add_device(), which does get_bus(). With a
refcount == 0, you hit the BUG().
The PCI bus type is registered in
drivers/pci/pci-driver.c::pci_driver_init(), which is a subsys_initcall.
pci_scan_bus() is called from arch/alpha/kernel/pci.c::common_init_pci().
It appears that this is called from pcibios_init(), which is also a
subsys_initcall. The arch/ objects are probably linked before the driver/
objects on alpha, so the bus ends up being scanned before the bus type is
registered.
Can pcibios_init() be demoted to a device_initcall? This would delay
probing until all the subsystems could be setup...
-pat
Patrick Mochel wrote:
> [ I apologize for answering this so late, and being so tardy
> in releasing
> docs explaining all this. I'll be sending docs to the list soon... ]
Alright. This is OK. :o)
[ ... ]
> The short of it: 2.5.19 introduced a struct bus_type that
> describes each
> bus type in the system. It holds lists of all the devices and
> drivers that are found for that bus type.
I guessed so and already found this out. :o)
[ ... ]
> The arch/ objects are probably linked before the driver/
> objects on alpha, so the bus ends up being scanned before the
> bus type is registered.
Seems, that you're right!
> Can pcibios_init() be demoted to a device_initcall? This would delay
> probing until all the subsystems could be setup...
Yea, great idea, but I don't have the time at the moment to do this.
I hope anybody else will (please) do it!?
-Oliver
Jan Benedict Glaw wrote:
[ ... ]
> > PS: Anybody want's the patches???
>
> /me
OK, I attached the patches:
a small part is from: Anton Blanchard;
a big part from: Ivan Kokshaysky
a small part from: me...
And I took an idea from: "[email protected]" (See the
2.5.20 Changelog)
-Oliver
Hi,
On Tue, 4 Jun 2002, Oliver Pitzeier wrote:
> Kernel bug at /usr/src/linux-2.5.20/include/linux/device.h:75
> I check what is on line 75 in device.h!
You find BUG_ON(atomic_read(&bus_refcount));
It might already be fixed by some of Irwing's patches.
> PS: Anybody want's the patches???
Sure as hell, if there are any new.
Regards,
Thunder
--
ship is leaving right on time | Thunder from the hill at ngforever
empty harbour, wave goodbye |
evacuation of the isle | free inhabitant not directly
caveman's paintings drowning | belonging anywhere
>>>>> On Tue, 4 Jun 2002 12:11:05 +0200, "Oliver Pitzeier" <[email protected]> said:
>> `copy_user_page' undeclared (first use in this function) make[1]:
>> *** [main.o] Error 1 make[1]: Leaving directory
>> `/usr/src/linux-2.5.20/init' make: *** [init] Error 2
Oliver> I guess I found where the error comes from:
Oliver> (from the 2.5.20 Changelog):
>> <[email protected]> [PATCH] pass "page" pointer to
>> clear_user_page()/copy_user_page()
>>
>> Hi Linus,
>>
>> Are you willing to change the interfaces of clear_user_page() and
>> copy_user_page() so that they can receive the relevant page
>> pointer as a separate argument? I need this on ia64 to implement
>> the lazy-cache flushing scheme.
>>
>> I believe PPC would also benefit from this.
>>
>> --david
Oliver> Now I believe, that Alpha also benefits from this. :o) The
Oliver> only thing I have to do - I guess - is to change the defines
Oliver> for copy_user_page() and clear_user_page. Adding the not
Oliver> used parameter >pg< should not make any problems.
Yes, you can simply ignore the page pointer argument. It's there for
those arches that want to take advantage of it. Sorry about causing
breakage...
--david
On Tue, Jun 04, 2002 at 08:19:49AM -0700, Patrick Mochel wrote:
>
> The short of it: 2.5.19 introduced a struct bus_type that describes each
> bus type in the system.
Which immediately collided with 'static struct bus_type {...}'
hidden in drivers/net/tulip/de4x5.c and, as result, the later does
not compile anymore. These two "bus_types" are quite dissimilar. :-)
An obvious and trivial fix was to globally replace "bus_type"
in de4x5.c with "de4x5_bus_type" (or this should be done in some
other manner).
Michal
Michal Jaegermann wrote:
>On Tue, Jun 04, 2002 at 08:19:49AM -0700, Patrick Mochel wrote:
>
>
>>The short of it: 2.5.19 introduced a struct bus_type that describes each
>>bus type in the system.
>>
>>
>
>Which immediately collided with 'static struct bus_type {...}'
>hidden in drivers/net/tulip/de4x5.c and, as result, the later does
>not compile anymore. These two "bus_types" are quite dissimilar. :-)
>
>
FWIW that s/bus_type/de4x5_bus_type/ patch was applied to 2.5.20 (and to
2.4.x too, even)
Jeff
Patrick Mochel writes:
> The problem: bus_types are registered with the system, which intializes
> all the internal fields, making them ready for use. The PCI bus is being
> probed before the PCI bus type has been registered.
We hit this on PPC too.
> Can pcibios_init() be demoted to a device_initcall? This would delay
> probing until all the subsystems could be setup...
No, because we have device drivers that are initialized with a
device_initcall and which reasonably expect the PCI subsystem to be
set up before they are called.
I can see two solutions: either rename "unused_initcall" to "sys_init"
or something similar and use it for sys_bus_init, or else make an
alias for fs_initcall called "bus_init" or something and use that for
pcibios_init.
Paul.
From: Paul Mackerras <[email protected]>
Date: Wed, 5 Jun 2002 08:00:25 +1000 (EST)
I can see two solutions: either rename "unused_initcall" to "sys_init"
or something similar and use it for sys_bus_init
See similar postings on this topic, with Subject
"Re: [2.5.19] Oops during PCI scan on Alpha"
There is a patch at the end of the thread which does
exactly as you describe.