> > Gah - I just get a panic rather early in the process. OTOH, I verified
> > that 2.4.27 does in fact boot OK when the 060 is disabled. No luck with
> > the various disk drivers yet, though. No idea what's up there.
>
> FWIW I remember something about trying stram_swap=0, but I don't know
> enoug
> Hi,
>
> is it possible to build a kernel that does not use the FPU part of CPU
> at all? I have tried to enable all the FPU_EMULATION config options of
> 2.4.27 but the kernel still uses FPU instructions...
That would be fsave and frestore, in order to save/restore FPU context on
behalf of user
On Sat, 18 Nov 2006, Adrian Bunk wrote:
> This patch removes video drivers that:
> - had already been marked as BROKEN in 2.6.0 three years ago and
> - are still marked as BROKEN.
>
> These are the following drivers:
> - FB_CYBER
> - FB_VIRGE
> - FB_RETINAZ3
> - FB_ATARI
FB_ATARI has just been re
> I tried with 2.6.18, but due to lack ATARI_FB I didnt see much except the
> bootlog of the kernel in the console. And it panicked not finding the root
> partition (which I found strange, since it did say it found the "disk")
You must be kidding? I did the whole Atari 2.6.18 patching on aranym (t
> Kolbjørn Barmen wrote:
> > Just curious.. have anyone done this?
>
> Michael did, I believe. Perhaps he could make a binary of the kernel
> (best with the aranym patches) available somewhere.
Please try
http://www.biophys.uni-duesseldorf.de/~schmitz/debian-68k/vmlinux-2.6.18-enec-test.gz
(fresh
> > You must be kidding? I did the whole Atari 2.6.18 patching on aranym (the
> > testing, anyways). That includes atafb support (see patches posted here,
> > and at debian-68k). Not to mention keyboard, aranym networking, and a bit
> > more.
>
> Any recent updates to those patches?
Not since I se
> > Any recent updates to those patches?
>
> Not since I sent the bunch to Christian for inclusion in the Debian
> kernels. I thought I had sent them to debian-68k as well at the same time,
> but I may be wrong there. The last stuff was the EtherNEC; I did some more
> dead code cleanup on atafb but
> > drivers/net/8390.c calls disable_irq_nosync_lockdep_irqsave and
> > enable_irq_lockdep_irqrestore in 2.6.19 now. The EtherNEC driver uses
>
> Yeah, I noticed these, too. Apparently we're the only arch with
> CONFIG_GENERIC_HARDIRQS=n using 8390.c.
>
> > 8390.c so we need these functions on m68k
Hi,
starting the Atari patch bomb on a light note: attached is the (minimal)
patch required to get Falcon IDE working. Tested under ARAnyM, may require
a slightly different solution once I get to testing SCSI properly (this
patch lets the IDE interrupt register on top of stdma_int which really
han
+ key_repeat_rate = 1;
+ }
+
+ k->delay = key_repeat_delay * 1000 / HZ;
+ k->period = key_repeat_rate * 1000 / HZ;
+
+ return( 0 );
+}
+
+int atari_kbd_translate(unsigned char keycode, unsigned char *keycodep, char
raw_mode)
+{
+#ifdef
Hi,
SCSI should be working on a TT (but someone should really try!) but causes
trouble on a Falcon (as in: it ate a filesystem of mine) at least when
used concurrently with IDE. I have the notion it's because locking of the
ST-DMA interrupt by IDE is broken in 2.6 (the IDE driver always complains
> Hi,
>
> SCSI should be working on a TT (but someone should really try!) but causes
> trouble on a Falcon (as in: it ate a filesystem of mine) at least when
> used concurrently with IDE. I have the notion it's because locking of the
> ST-DMA interrupt by IDE is broken in 2.6 (the IDE driver always
Hi,
this isn't really my kettle of fish, but I post it anyway unless Petr
complains :-)
This is what makes it possible for me to test 2.6 builds on the
emulator...
Should be signed off by Petr, really.
Michael--- linux-2.6.19-m68k-cvs/arch/m68k/atari/config.c 2006-12-02
00:16:50.0
Hi,
once again, I messed up. _This_ one is the IDE patch (already in Linus'
tree as Geert told me). The other one was ARAnyM; please ignore.
Michael--- linux-2.6.19-m68k-cvs/arch/m68k/atari/stdma.c 2006-12-02
00:16:51.0 +0100
+++ linux-2.6.19-m68k/arch/m68k/atari/stdma.c
> > vger refused the atafb patch again, that's why I spammed Geert by CC: on
> > all this, sigh.
>
> BTW I pretty much rewrote the bit plane stuff, so it doesn't constantly
> corrupts the output.
??? When did you get to see output corruption? Can you send me your
rewrite for testing? (Though Arany
> > > BTW I pretty much rewrote the bit plane stuff, so it doesn't constantly
> > > corrupts the output.
> >
> > ??? When did you get to see output corruption?
>
> I see a corrupt penguin (huhuh) when using video=atafb:vga256 on aranym.
>
> http://amiga.nvg.org/moro/aranym.png
That I can believe (
> > ??? When did you get to see output corruption? Can you send me your
> > rewrite for testing? (Though Aranym should suffice for testing, really)
>
> I was testing with vga256 and pretty much any line edit operation which
> calls copyarea or fillrect causes a corrupt output (i.e. anything besides
> > 8390.c so we need these functions on m68k now. I've just added dummy
>
> Be careful with 8390 anyway, as Al Viro rewrote it, cfr. the current git tree
> and 2.6.20-rc1 soon.
OK; please hold off merging these bits; I might actually get away with
confining the ROM port IO hacks to the ethernec d
> > Signed-Off-By: <[EMAIL PROTECTED]>
>
> SCC_clocks is unused. Is this intentional?
>
> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
>
> --- linux-m68k-2.6.19.orig/drivers/char/atari_scc.c 2006-12-12
> 21:52:31.0 +0100
> +++ linux-m68k-2.6.19/drivers/char/atari_scc.c20
> > > Should be signed off by Petr, really.
>
> Atari NatFeat Ethernet fixes:
> - Interrupt handlers no longer pass around a struct pt_regs *
> - Always return the interrupt handled status in atari_nfeth_interrupt()
> - Fix incorrect prototype of atari_nfeth_probe()
>
> Signed-off-by: Geert U
> > Second part: Atari keyboard and mouse support.
> >
> > Signed-Off-By: <[EMAIL PROTECTED]>
>
> Atari keyboard and mouse fixes:
> - Kill unused variables
> - Add missing declaration of atari_keyb_init()
>
> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
Looks OK to me :-)
Mic
> On Mon, 11 Dec 2006, Michael Schmitz wrote:
> > my final atafb version (modedb set up for Atari modes, although I'm not
> > sure the timing data make much sense). Leftover dead code removed. Same
>
> Indeed, you want to replace TAG_*RES by the actual pixel clock value
> > > Indeed, you want to replace TAG_*RES by the actual pixel clock values.
> >
> > And I sure wish I knew these :-) Same for the detailed timings. What do I
> > need to provide in the driver so fbset can report these data?
>
> Didn't the video modes in the old atafb have correct timings?
We neve
> > We never had a modedb in the old code. The timing is hardcoded in the
> > driver from all I can see. I was under the impression the fbcon code needs
> > to have the modedb entry for some purpose; atafb sure can do without
> > otherwise.
>
> But at least the various old *_encode_bar() routines f
> > But at least the various old *_encode_bar() routines filled in the values,
> > so
> > you can use these for your modedb array.
>
> Well, sort of. The TT driver filled in fixed data, the Falcon driver
> calculates them according to the monspecs. I've done a bit of head
> scratching and a few ed
> > LDFLAGS_MODULE += -T $(srctree)/arch/m68k/kernel/module.lds
> > ifneq ($(COMPILE_ARCH),$(ARCH))
> > # prefix for cross-compiling binaries
> > - CROSS_COMPILE = m68k-linux-
> > + CROSS_COMPILE = m68k-linux-gnu-
> > endif
> >
> > ifdef CONFIG_SUN3
>
> Hmm, this part was accidental, bu
> > SCSI should be working on a TT (but someone should really try!) but causes
> > trouble on a Falcon (as in: it ate a filesystem of mine) at least when
> > used concurrently with IDE. I have the notion it's because locking of the
> > ST-DMA interrupt by IDE is broken in 2.6 (the IDE driver always
> > That driver really needs more work. Several things in it have become
> > obsolete, e.g. it still uses sleep_on() and manages it's own queue.
>
> Throw me a few more hints, please. I already knew about error handling
> being changed; what should I use for sleep_on(), and will the driver still
>
Hi,
Roman's latest CVS updates broke IDE (ST-DMA) locking on the Falcon.
Reason: calls to ide_get_lock and ide_release_lock are not guaranteed to
be balanced. I fact, the very few first IDE operations leave the driver
with a perceived imbalance of four excess lockings. Don't ask me why this
happen
> > Throw me a few more hints, please. I already knew about error handling
> > being changed; what should I use for sleep_on(), and will the driver still
> > be able to release the ST-DMA lock on request done if queue management is
> > done by the midlevel?
>
> On second thought - the sleep_on we c
> > Christian, please apply this on top of my other 2.6.18 patch.
>
> Fails to apply, even when I remove the previous scsi patch first. Did you
> check out the debian patches from svn? 2.6.18 is in dists/sid/linux-2.6
Nope, I just took the patch relative to what I thought was the last clean
state
> > macmace: tx ring ran out? (fs=80)
> > [...]
>
> Interesting. I rarely saw those messages in my tests, so I guess I should
> try different workloads. That message is triggered with only 1 or 2
> packets in the TX DMA ring buffer, but I don't know if it is meaningful
> (it comes from mace.c, whic
> > Maybe the message can be disabled, if just a few packets in the transmit
> > ring is normal for macmace :-)
>
> Yes, that's normal, but the same tx_count variable that triggers the "ran
> out" message when 0 also trips the netif_wake_queue when non-zero, which
You mean netif_wake_queue gets ru
> This could be caused by some of the patches I'm using, or my .config or
> just because I'm using 2.6.19 not 2.6.18. But mac_scsi seems to be broken
> either way (I know it worked around 2.6.10). Looks like I'm going to need
> an NFS root filesystem to test Mac II ADB on the older machines.
2.6.1
Hi,
>
> Does anyone know why the PT_* definitions in include/asm-m68k/ptrace.h:
>
> | #define PT_D1 0
> | #define PT_D2 1
> | #define PT_D3 2
> | #define PT_D4 3
> | #define PT_D5 4
> | #define PT_D6 5
> | #define PT_D7 6
> | #define PT_A0 7
> | #define PT_A1
> > Some stray interrupt coming in while SCSI is probing, and messing up
> > things in the interrupt handler? Does it hang with interrupts disabled?
>
> Could be. It is a very racey bug, in that it is intermittent and is worse
> on some models than others. And with 2.6.18-4 it is harder to trigger
> > Looks like the PT_* offsets are in units of long, but otherwise correct?
>
> Nope, we have PT_D7, but no pt_regs.d7.
If that's all ...
> > > I was trying to define task_thread_info() using TASK_INFO instead of using
> > > struct task_struct directly (cfr. ia64), but these conflicts seem to
>
> > I've got the Mac IIsi ADB driver half working now. It stops working when I
> > remove some printks... sigh.
>
> I seem to recall the last time someone worked on the IIsi ADB driver
> that it was insanely sensitive to exact timing. While I haven't tried it
Yep. I'm amazed to hear it used to wor
> VFS: Mounted root (ext3 filesystem) readonly.
> Warning: unable to open an initial console.
> Kernel panic - not syncing: No init found. Try passing init= option to
> kernel.
There's no Linux root filesystem on your hda1
Michael
-
To unsubscribe from this list: send the line "unsubscri
> But with this http://web.zln.cz/~joy/aranym-linux-kernel-2.4.27-12.tar.gz
> kernel it can find init and is booting normally from the same image.
Strange.
> Or do you mean that the 2.6 kernel needs something else then was present
> in Etch by August 2006 as Petr was creating that image?
Not lik
> > ide0: Falcon IDE interface
> > mice: PS/2 mouse device common for all mice
> > VFS: Cannot open root device "hda1" or unknown-block(0,0)
> > Please append a correct "root=" boot option
> > Kernel panic - not syncing: VFS: Unable to mount root fs on
> > unknown-block(0,0)
>
> I haven't tried the
> > If I tested them, I also sent in patches :-) I haven't tested
> > any 2.6.18 kernels in a while, though. In particular, I cannot remember
> > ever seeing these IRQ 5 -> 0 stuff.
>
> Don't worry about those IRQ lines, I have added those to see what is the
> problem there and to be able to report
> > I'm guessing that possibly the interrupt is not being ack'd correctly
> > (perhaps the act of testing it clears it)... or maybe slot F doesn't get
> > latched like the others (perhaps because it is effectively cascaded 3
> > deep). I need to do more experimentation.
>
> I've finally fixed it! (
> > > 1. Don't exit the nubus interrupt handler until there's no irq flagged.
> >
> > Which may yet kill us if we don't manage to ack (think graphics cards
> > here).
>
> Yes. I've seen this occasionally on my LCIII (the 8390 network card IRQ)
> ... no problem yet on the Q650, LC630 and IIsi. But t
> > Workqueue updates for the Atari EtherNEC driver (does this make sense?)
>
> These changes yes, but while I looked at the driver I noticed a few other
> things.
I'm not sure whether this could introduce more delays - OTOH the work
queue is just a fallback in case I cannot get a timer interrupt.
> static volatile int main_running;
> -static DECLARE_WORK(NCR5380_tqueue, (void (*)(void *))NCR5380_main, NULL);
> +static DECLARE_WORK(NCR5380_tqueue, NCR5380_main);
>
> static inline void queue_main(void)
> {
> @@ -1075,7 +1075,7 @@ static int NCR5380_queue_command(Scsi_Cm
> * reenable the
> I don't think the CONFIG_ATARI_ROM_ISA definitions are complete yet, the
> 32-bit variants are missing.
They are not needed (the ROM port has to share address lines for reads and
writes, neither data nor address path of 32 bits is possible there.
Michael
-
To unsubscribe from this list:
> > > I don't think the CONFIG_ATARI_ROM_ISA definitions are complete yet, the
> > > 32-bit variants are missing.
> >
> > They are not needed (the ROM port has to share address lines for reads and
> > writes, neither data nor address path of 32 bits is possible there.
>
> So they should be dummies,
> > I don't think there's enough traffic to justify a separate list these days.
>
> And it's easier to hunt for patches on linux-m68k only.
Plus it's unmoderated (my last few posts to linux-mac68k went to the bit
bucket).
Michael
-
To unsubscribe from this list: send the line "unsubscribe
> I tried to add m68k patches for 2.6.20 to the debian linux-2.6 package, but
> compilation fails here:
>
> AS arch/m68k/math-emu/fp_scan.o
> arch/m68k/math-emu/fp_scan.S: Assembler messages:
> arch/m68k/math-emu/fp_scan.S:67: Error: Unknown operator -- statement
> `getuser.b (%a0),%d0,fp_e
> > > Update the atari fb to 2.6 by Michael Schmitz,
> >
> > Finally :-). That leaves only pm3fb that needs porting.
> >
> > It still contains remnants of 2.4 code though, ie, FBCON_HAS_*, but
> > that's minor.
>
> Yeah!!! Its a good step forward
> > > +#define BUS_ATARI0x1B
> >
> > Is this really a separate bus? Should't we have a BUS_ONBOARD or so
> > instead?
>
> BUS_HOST shoudl fit the bill.
OK, I'll use that one.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a mes
On Tue, 1 May 2007, Christoph Hellwig wrote:
> What's the reason for splitting this up? Things would be a quite a bit
> simpler if all the code was directly in atakeyb.c.
Simple: I assumed that keeping the input driver code with the other input
stuff was the Right Thing. I can move everything ba
> > > What's the reason for splitting this up? Things would be a quite a bit
> > > simpler if all the code was directly in atakeyb.c.
> >
> > Simple: I assumed that keeping the input driver code with the other input
> > stuff was the Right Thing. I can move everything back to atakeyb.c if
> > that
> > +static unsigned char rep_scancode;
> > +static struct timer_list atakeyb_rep_timer = {
> > + .function = atakeyb_rep,
> > +};
>
> Is there a problem with repeat implementation in input core that
> requres custom-made repeater here?
Apparently not - the homebrew repeater has not been act
> > > > + // need to init core driver if not already done so
> > > > + if (atari_keyb_init())
> > >
> > > Memory leak
> >
> > How so? If the core has been initialized already this will just return ...
> >
>
> You just allocated atakbd_dev. If atari_keyb_init() fails you leak it.
I see.
> > > `default y if M68K && SYSV_FS'
> >
> > I prefer `default y if VME'.
> >
>
> Incidentally, what is the problem you have with SYSV68_PARTITION ?
> On my i586 machine, code size is 434 bytes for sysv68.o + 4 bytes more in
> check.c
Traditionally, we have always been very conservative about en
On Sun, 20 May 2007, Geert Uytterhoeven wrote:
> On Sun, 25 Feb 2007, Kars de Jong wrote:
> > On vr, 2006-11-03 at 00:06 +0100, Kars de Jong wrote:
> > > On do, 2006-11-02 at 22:34 +0100, Geert Uytterhoeven wrote:
> > > > > OK, here's the patch, without the m68k generic iomap changes.
> > > >
> >
> > Note that both 16 and 32 bit accesses will return 8 bit results only, due
> > to the way the address and data bus are wired on the ROM ISA adapter. I
> > hope this is the correct behavior.
>
> I don't think that's correct. Shouldn't 16-bit resp. 32-bit accesses be
> emulated using 2 resp. 4 8-b
Hi Geert,
> > Note that both 16 and 32 bit accesses will return 8 bit results only, due
> > to the way the address and data bus are wired on the ROM ISA adapter. I
> > hope this is the correct behavior.
>
> I don't think that's correct. Shouldn't 16-bit resp. 32-bit accesses be
> emulated using 2
> > +#define rom_out_be16(addr,w)
> > \
> > +({u16 __w, __v;
> > \
> > + __v = (w) >> 8;\
> > + __w = ((*(__force volatile u16 *
elSubject: [PATCH] m68k: Atari ROM port ISA adapter update
Atari ROM port ISA adapter support - missing bits for generic IO support
Signed-off-by: Michael Schmitz <[EMAIL PROTECTED]>
---
io.h | 21
raw_io.h | 82 +--
Hi Geert,
> I've just upgraded my poor old A4000 (which had been in in storage for 2.5
> years) from Debian woody to sarge, but hotplug and udev break havoc on it:
Good to hear (that your A4000 is back up now, not the breakage of course
:-)
> I've also been thinking about adding a special `amiga
> > > What do you think?
> >
> > We would need something like that anyway, in order to convert drivers to
> > the new generic driver model, if I understand it right (the only driver
>
> The alternative is to keep (convert to, for some) them as platform
> devices. But that means no auto-load based o
m68k: Atari input drivers cleanup
- memleak on failed init/register of input devices fixed
- correct keycodes table (Atari keycodes are almost, but not entirely, equal
to Linux keycodes).
Signed-Off-By: Michael Schmitz <[EMAIL PROTEC
> From: Geert Uytterhoeven <[EMAIL PROTECTED]>
>
> m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible
With buttons emulation being available via uinput event devices, do we
still need the kernel mouse button emulation? At least on powerpc, it was
declared deprecated long ago ...
A
> > Anyone using mouseemu on m68k Mac?
>
> Yes, and on powermac too. It provides the paste key for gpm and I'm quite
> fond of it. But if there's a better alternative, I'll happily try it
> instead.
Too much overhead on m68k? On powermac it never gave me trouble, but I was
surprised to hear people
> o These days we have scripts/checkpatch.pl. I fixed most patches,
> except for:
> . 633-atari_scc.diff
> . POSTPONED/143-ioext.diff
> . POSTPONED/149-mc68681.diff
> . atari-ethernec.diff
I'll take care of scc and ethernec.
Michael
-
To unsubsc
TED]>
> Cc: Dmitry Torokhov <[EMAIL PROTECTED]>
> Cc: Michael Schmitz <[EMAIL PROTECTED]>
Ack, Ack ...
Thanks, Geert! Can't wait to get my Falcon back outta the container ...
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-m68k&qu
Hi Geert,
this patch is needed to make the Atari EtherNEC driver with the associated
ROM port ISA I/O stuff compile again. This is relative to your quilt patch
queue and git 2.6 as of yesterday. Please apply.
Michael
Signed-Off-By: <[EMAIL PROTECTED]>
--- include/asm-m68k/io.h.ms-ethern
I need to select MMIO either as module or
> > builtin, depending on how the EtherNAT driver is built. That does not
> > appear to be automatic yet.
>
> You mean MII? Doesn't `select MII' do the right thing?
Did fail (MII compiled in when driver was modular) at least o
Hi,
> > As device_initcall? May be cleaner indeed. I was glad I found the initcall
>
> Just use module_{in,ex}it().
>
> > trick at all... Does that work on module load as well?
>
> Yep.
I'll try that.
> > > > other one is a kconfig issue - I need to select MMIO either as module or
> > > > builti
Hi Geert,
> > > As device_initcall? May be cleaner indeed. I was glad I found the initcall
> >
> > Just use module_{in,ex}it().
> >
> > > trick at all... Does that work on module load as well?
> >
> > Yep.
>
> I'll try that.
Works, and the only problem is that I need to unregister the device on
m
Hi,
thanks for catching this ...
> This patch fixes the following build error:
>
> <-- snip -->
>
> ...
> MODPOST 25 modules
> ERROR: "atari_keyb_init" [drivers/input/mouse/atarimouse.ko] undefined!
> ERROR: "atari_keyb_init" [drivers/input/keyboard/atakbd.ko] undefined!
> make[2]: *** [__mod
Hi all,
> > Several fixes are possible; I'll try the most generic one next.
>
> I am curious what the fix will be (with regard to that Geert's remark).
I'm getting a bit confused - the good old mach_max_dma_address variable
does not seem to get used in the recent kernels anymore at all. Could a m
Argh. Forgot to mention two important bits:
- the allocator is unfinished (no way to free statically allocated bits,
and code allocating chunks off the freed list is dodgy)
- this patch is not meant to be merged yet.
Another thing I noticed while testing the patch: ataflop and atari_scsi
now
>From [EMAIL PROTECTED] Thu Jan 3 02:53:38 2008
Newsgroups:
Date: Thu, 3 Jan 2008 02:53:38 +0100 (CET)
From: Michael Schmitz <[EMAIL PROTECTED]>
To: Petr Stehlik <[EMAIL PROTECTED]>
cc: Michael Schmitz <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]>,
Subject: Re: ara
Hi,
> As to your question regarding the most generic fix: if there really is not
> enough ST-RAM (i.e. the available space is taken by the kernel and the
> ramdisk, after 'unpacking' the ramdisk to the buffer cache) we'd need to
> either make the ramdisk unpack go to non-DMA memory (no idea here;
Hi all,
> > Anybody who can look into converting the m68k NCR53C9x drivers and has
> > hardware to test (some of) them? I don't think we can afford losing one
> > third of our SCSI drivers...
I can look into converting some (having worked on the m68k Mac ESP driver
in the past - I do recall the M
Hi,
> > > Hopefully this patch includes all the of feedback from the last one.
> > > This patch adds a character device driver to allow user space access
> > > to the aranym natfeats nfstderr.
Great (even though, in the light of Geert's explanation of /dev/console,
one wonders if console=/dev/tty
> > > BTW, I am amazed by simplicity of the patch and am wondering if it is
> > > similarly simple to write a disk driver (to avoid the IDE emulation in
> > > ARAnyM).
> >
> > I don't think it's quite as simple.
>
> Not nearly as simple - you won't get away with a single fops, for
> starters. OTOH
Hi,
> One of the recent IDE changes seems to have broken Atari Falcon IDE.
> My smoke test boot on Aranym gives:
>
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
> ide: Falcon IDE controller
> Unable to handl
Hi Geert,
> I just tried to update zorroutils, but I got the following error from
> cvs:
>
> | cvs [diff aborted]: connect to cvs.linux-m68k.org(134.99.176.32):2401
> failed: Connection timed out
>
> 134.99.176.32 points to placebo.biophys.uni-duesseldorf.de
Big oops - that used to point to kull
Hi,
> > - Modify the linker script (vmlinux.lds) to stick the build-id section
> > somewhere --
> > .note.gnu.build-id : { *(.note.gnu.build-id) }
>
> OK. I don't know whether the build-id section is better removed or kept,
> so I'll leave it to others to send a patch.
It's perhaps a good idea to
Hi,
> > The only missing bit is to skip the writeback, as the fault has to be
> > first fixed by the caller, so the patch below should do the trick...
>
> It does indeed do the trick!
> Thanks, Roman.
No more access faults from kernel space possible this way? What happens
with PDMA commands that
Hi Geert,
Regarding performance afforded by having a 100 Mbit PHY instead of a 10 Mbit
one:
EtherNAT: 210 KB/s out, 140 KB/s in (scp of a 35 MB vmlinux file)
EtherNEC: 175 KB/s out, 128 KB/s in (same file)
Hardly worth it, eh?
That's slower than my Ariadne?
Still no interrupts.
BTW, do y
bug" errors reported
by Stephen R Marenka.
Cc: Geert Uytterhoeven <[EMAIL PROTECTED]>
Cc: Michael Schmitz <[EMAIL PROTECTED]>
Cc: Stephen R Marenka <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Objected: Michael Schmitz <
Hi,
I don't know "how", but with 2.2 kernels I always had a correct date
at boot without any tricks. It is true though that with high CPU load
we had clockskew and that we didn't save back the date and hourtime to
the clock, thus any clock setting needed to be done from the mac side.
A comprom
Hi,
Valid point. I gues penguin still does pass the date, so the problem boils
down to 'why isn't it used by the kernel?'
EMILE passes the date too.
Good, so solving the problem should fix it for both. When did the problem get
introduced - 2.4 or 2.6?
Michael
--
To unsubscribe fr
Hi,
Good, so solving the problem should fix it for both. When did the problem
get
introduced - 2.4 or 2.6?
Silly question I guess, but how is the passing done?
On m68k architecture, bootloader passes a list of tags to the kernel, see
set_kernel_bootinfo():
Short answer: bootinfo.
I'm co
Hi Geert,
On Thu, 23 Oct 2008, Geert Uytterhoeven wrote:
On Thu, 23 Oct 2008, Michael Schmitz wrote:
It seems to be removed in early 2.5 (2.4 has it, my oldest 2.5 is 2.5.5
and that one doesn't have it anymore):
and `mach_gettod' was wired up to 'mac_gettod'.
No idea w
Hi,
> > I'm confident the date/time is passed by bootinfo OK, but it then
> > 'disappears'.
>
> Yep, nothing is done with mac_bi_data.boottime, except for printing it
> to the kernel log.
>
> > I'm pretty sure it was still OK in the 2.2 series - I'm unsure on when it
> > broke: 2.4 or 2.6?
>
>
> > Test and improve, please.
>
> I think the patch won't work because the catchall is never invoked.
My bad - I thought the problem was related to a missing RTC driver on those
Macs in question.
> I'd use a new kernel parameter for this (if I thought we needed another
> workaround) rather t
Hi,
> > At least the Quadra 900 and 950 have two SCSI buses, as deducted from
> > Finn'ss
> > recent patch.
>
> It is also possible to add SCSI buses. I have a NuBus SCSI card that has
> a 53c9x chip of some flavor on it, although I haven't tried it and suspect
> that it would take some work to
Hi,
> > The 53C9x won't be that hard, but you'll have to write register access code
> > going through NUBUS instead of memory mapped IO. The NUBUS ethernet drivers
> > should have plenty of sample code. Leaves the exercise of locating the chip
> > in the slot address space :-)
>
> Well, I did
Hi Geert,
> > > When Michael thinks they're ready, he can submit them to netdev or
> > > linux-scsi
> > > ;-)
> >
> > I'm happy for them to live in linux-m68k :-)
> >
> > EtherNEC and EtherNAT are 'ready' in the sense they are working reliably.
> > They
> > are by no means 'ready in the sense
Hi,
> So far the only platform device for m68k (not in mainline) is Michael's
> EtherNAT driver, cfr. arch/m68k/atari/config.c. Note that that one registers
> the platform device unconditionally, as there's no magic predictor for its
> presence in the firmware or machine tables.
There's no magic
Hi Geert,
> Make sure fix->line_length is always set, as some applications need it because
> they don't have fallback code if line_length is zero.
I did set line_length to zero for a reason while hacking on the driver, but my
recollection of the reasons is quite fuzzy. I'll give it a test run on
Hi Geert,
On Tue, 18 Nov 2008, Geert Uytterhoeven wrote:
> (Finally) I created an experimental git tree for Linux/m68k:
> http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git
Sweet :-) Cloning already.
> It contains more or less all patches I had in my quilt series at
> http://www.k
Hi Geert,
> Make sure fix->line_length is always set, as some applications need it because
> they don't have fallback code if line_length is zero.
>
> Works on ARAnyM (Falcon emulation), but par->next_line is not set on any other
> Atari variant?
You're right - while testing on the Falcon frameb
1 - 100 of 992 matches
Mail list logo
