Re: Save trackpad settings during sleep
>On the Lombard, the ADB devices are apparently reprobed and reset before >pmud restores the device state. If BenH is doing something differently on >the iBook that prevents pmud from finding the device after sleep we'd >better save the device state in the kernel and restore it there to be >safe. My recent kernels made ADB probing asynchronous. Not yet merged in the main tree but it will definitely kill the pmud script. I guess proper management of the trackpad should be done in the kernel driver (and I may have other reasons for that, I'm not sure it's always safe to read the trackpad registers, looks like this would explain the old problem of trackpad vs. cmode:32 on some Pismo's). I noticed Darwin kernel changed their driver code to not read the config regs, but rewrite them all from RAM cached ones some time ago (before 10.0) Ben. -- RFC822 Header Follows -- From: <[EMAIL PROTECTED]> To: Michael Schmitz <[EMAIL PROTECTED]>, Subject: Re: Save trackpad settings during sleep Date: Wed, 13 Jun 2001 20:15:22 +0200 Message-Id: <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> X-Mailer: CTM PowerMail 3.0.8 <http://www.ctmdev.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ---
Re: switching to linux keycodes in woody
>As far as I can tell, this problem could only be solved by continuing to >provide separate keymaps for Intel and Mac, at least for non-US >keyboards. Yes, it's necessary to ship both four countires where the layout differ. Note that Linux keycodes are still a good thing for other reasons, one beeing that you can plug a PC style USB keyboard, use a PC keymap and it will work on the mac. That was not true with the ABD keycodes. Ben.
Re: XFree86 4.1.0: call for help
>If it indeed allows the server to start without Option "UseFBDev": yes. Can't >hurt to try I guess... BenH seemed to suggest that it really can't work this >way though. > It may work. Depends if you get the iobase from the AGP bus or the PCI bus. What can't work is both... Ben.
Re: XFree86 4.1.0: call for help
>Hmm you have a point there, i have a feeling that the text/colormap >was not crasing in the isa i/o access but in the isa mem ones, >(we mmap 0xA, i wonder what lives there since isa mem definitely >isn't) RAM. Actually kernel code :( There no way to access ISA mem on most Macs. >We don't need any more kernel assistance, just to fix the syscall to >return an error for the AGP bus of Uni-N if we can't do any io there. We can do _IO_, not ISA mem. Some cards require IOs accesses to some VGA registers so we need the syscall to work. IOs are indeed possible on all the UniNorth busses. >Since 4.1 went out broken we can't do much now, the best solution will >be to disable the ioctl (since we don't get the right base anyway) How ? If you get base for bus 0, you'll get the AGP which is what you are looking for in this case. Ben.
Re: XFree86 4.1.0: call for help
>The segfault occurred in an inb(), is that also used for ISA mem? If you get that for read and not write, then you are probably getting machine checks, which usually means IO to an incorrect address. Are you sure your card is answering to VGA IOs ?
Re: powerpc ready for freeze?
On Tue, Dec 28, 1999, Ivo KRAB <[EMAIL PROTECTED]> wrote: >In general, I think debian is quite poor in keymaps for the mac hardware. >I'm trying to generate a series of keymaps based on the MacOS 8.5 >resources, but I have little time to do a complete table-translation for >all the international versions, although this could be automated. The >resource formats are nicely documented. An automated tool for that would be The Real Good Idea of the year ;) I've been wanting to do that for monthes and never took the time (I'm still typing blindly on my French keyboard with an US keymap ;) >* The problem that the kernel on the boot-disks does not fit with the >modules was not yet resolved last week. Please make something consistent >there, so also PCMCIA could work (I have a PCMCIA modem, I only could Would it be possible to add an option to miBoot (oldworld machines with floppy) so that it loads the kernel from the floppy, and then requests another floppy for the ramdisk ? This would be less useful to add to yaboot since all newworld machines are floppy-less. (It's possible that the latest ones can boot from a USB floppy however).
New 2.2.14 for iMac/iBook/G4
I've uploaded a new version of my kernel. It's now based on final 2.2.14 and contains a few more fixes. It's at the usual URL: http://calvaweb.calvacom.fr/bh40/test.html WARNING ! There's a problem with the amd daemon and this kernel. I don't know yet if it's specific to my kernel or a more generic 2.2.14 issue, but on my machine, amd crashes the kernel at startup (or makes it oops I beleive when xmon is disabled). Remove amd from your init.d to fix the problem, or eventually upgrade to a newer amd (I think I was still using the old one from linuxppc Q3). This is the only problem found so far. Note: The USB mouse is still (c 10 32) protocol imps/2, unlike Paul's rsync tree. Have fun ! Ben.
Re: xfree
On Mon, Jan 10, 2000, Shiryu <[EMAIL PROTECTED]> wrote: >There is a server, called Xpmac, that is actually acelerated for ATIcards, and >is not on debian, is damm much faster than the frame buffer there's a version of xpmac accelerated for the 65550. Ask on the linux-ppc mailing lists, or look at the various web sites, you should be able to find it.
Re: about PowerPc - offtopic
On Mon, Jan 10, 2000, hughc <[EMAIL PROTECTED]> wrote: >Of course, if disk-intensiveness is a large part of the compiling process, you >probably need to spend a fair amount of time with hdparm before it works at >it's >best. According to it's built-in benchmarks, disk throughput practically >doubled >on my 400 mhz "Bronze" laptop when I set it to autotune. > >Is hdparm available with Debian? depending on which options you used when the kernel was compiled, this may be done automatically. My latest "ibook" kernel contains some IDE changes that will automatically set the disk to the best support DMA mode.
Re: Kernel 2.2.14
On Wed, Jan 12, 2000, Hugh Caley <[EMAIL PROTECTED]> wrote:
>I am also getting crashes with the 2.2.14 kernel. I made the ohci changes
>mentioned below, and neither parport nor PC serial port is configured ("dumb"
>support is configured as a module), but I still get a "machine check" kernel
>panic at boot. This is also on a Lombard. I have been successfully using
>2.2.14pre9 for a while, which I also compiled from Paul's rsync source.
Could you lookup in the System.map where the machine check actually
happens ? This would help me figure out what's wrong and fix it.
Re: Kernel 2.2.14
I also forgot to mention: The problem I had here was that the debian boot script actually insmod'ed the dumb serial module, thus causing the crash. This is the piece of script that displays "Configuring serial ports".
Re: Kernel 2.2.14
On Wed, Jan 12, 2000, Hugh Caley <[EMAIL PROTECTED]> wrote: >Hi, Ben. I don't seen an entry in System.map that contains both "machine" and >"check". There are a whole bunch of "check"'s, however. Machine check is a standard ppc exception that usually happens when trying to use non-existing hardware. That's why I beleive one of your init scripts is causing serial.o to be insmod'ed incorrectly. (This just happened to me todday with debian/ppc on a 8500 and a 2.2.14 kernel). To find out where the error actually happened, look at the "NIP" field of the error, and lookup this address in System.map to find out which routine is related.
Re: Kernel 2.2.14
On Fri, Jan 14, 2000, Jason E. Stewart <[EMAIL PROTECTED]> wrote: >Well it boots, but I still don't get access to APM. How does one >configure it? Power management on powerbooks exist but is not APM for now (it's specific). You should get the pmud tool (available somewhere on ftp.linuxppc.org or linuxcare.com.au)
Kernel rev12 online
It's at http://calvaweb.calvacom.fr/bh40/test.html as usual. The amd problem no longer happens on my box. New with this release: - Removed code that reads nvram for default mode on Rage 128 (broken) - Fixed various PowerBook media-bay,IDE & snooze issues - Reverted a change which happened to break the serial port of the wallstreet - Fixed coff boot. vmlinux.coff should now work again. Successfully netbooted an oldworld wallstreet powerbook from OF with this kernel. - Added a block_dev.c fix from 2.2.15pre2 - Included a newer version of aty128fb which supports 16bits mode Notes: - dmasound works on Sawtooth when booting with OF, but hangs with BootX Application. That's why it's compiled as a module. - There's a problem with aty128fb when specifying the vmode from the kernel arguments. It's not passed correctly to Xpmac. Set the vmode again with vmode to make Xpmac work. (You can add the vmode call to your rc.sysinit) Have fun ! Ben.
Re: Kernel rev12 online
On Sun, Jan 16, 2000, Hartmut Koptein <[EMAIL PROTECTED]> wrote: > Is this tested for chrp, prep, apus, common, ... ? No it's not since I don't own any of these machines. It's tested on powermacs only for now. I hope I didn't break anything, so it should work on the same HW that Paul's stable rsync tree supports but it's not tested.
Re: gnapster
On Sun, Feb 6, 2000, Renaud Dreyer <[EMAIL PROTECTED]> wrote: >Has anyone managed to get gnapster (MP3 search engine) working on a >PowerPC machine? All I get is a permanent: > >Connected (208.184.205:)...wawiting login reply... > >with the following error messages: > >network_conn_real_cb >unknown[3] -> [EMAIL PROTECTED] >unknown[214] -> 1825 151376 605 >unknown[214] -> 1825 151376 605 >unknown[214] -> 1824 150836 603 >unknown[214] -> 1827 150622 603 >... > >I get a weird memory allocation errot with gnome-napster, and can't >connect wither with gnap. Thanks, The latest gnapster (1.3.4) has been fixed and works on PPC.
Re: netboot-capable pmacs (was Re: booting from openfirmware)
On Tue, Feb 8, 2000, <[EMAIL PROTECTED]> wrote: >Since you've done some netbooting, i figured i'd ask ... do you know what >Mac models can be successfully booted from the network? Apple says only >NewWorld macs, but a) that's for OS X's NetBoot Server b) it's Apple, >they lie c) obviously there's some OldWorld things that can netboot as >seen from your experience. I've been screwing around with a 4400/200 >but it seems not to even have an OF driver for its ethernet card >(DLINK-530 (Tulip)). So obviously there are some that don't work as >well. *grumble* I kinda wish Apple would release ROM upgrades for >these flaky old machines... I can't tell for sure. I think all bmac/heathrow based machines (with OF 2.x) can netboot. You may want to look at NetBSD PPC FAQ since they used to netboot a lot more that we did.
Re: booting from openfirmware
On Tue, Feb 8, 2000, Logan Hall <[EMAIL PROTECTED]> wrote: >Cool. Is there a way to install it with out MacOS X server? Will it be >included with MacOS X Client do you think? I don't know.
Re: [Whats the deal with ppclinux.apple.com?]
On Fri, Dec 22, 1944, jeramy b smith <[EMAIL PROTECTED]> wrote: >> >> Ive seen numerous pages refering to 'ppclinux.apple.com/~benh' and the >server >> seems to not exist. Do you know anyone who has mirrored his files? Im >trying >> to install ppclinux on my roomate's G4 for the experience and i need the >> precompiled kernel that he has there. >> > >This page is an unnofficial Apple page. Go to #mklinux on EFNet and someone >will probably have the scoop on what's wrong and may even be able to dcc you >the kernel. > >You may also want to check out the kernel folders at the different linuxppc >sites if your in a hurry. I think there may be supplemental G4 kernels in the >distributors' ftp sites. The server ppclinux.apple.com is down due to a human error ;) (Someone just manage to break physically the machine). It will be back up Monday.
Re: /etc/X11/Xmodmap re-revisited
On Wed, Mar 1, 2000, Branden Robinson <[EMAIL PROTECTED]> wrote: >Actually, I've decided to do the sensible (?) thing and identify the >keycodes by keyboard model rather than the machine architecture. One way >or another you can probably manage to plug a PC keyboard into just about >anything, so it doesn't make much sense to refer to it as an "i386" >keyboard. > >Comments? Suggestions? The last time I looked at the USB keyboard driver, it was broken enough to prevent you from doing that. basically, it will either convert the keycodes to PC keycodes if you are compiling for i386, or to ADB keycodes if CONFIG_MAC_KEYBOARD is defined, or will just not compile if neither of them is defined. I'll see with the maintainer if this can be changed to simply use PC keycodes all the time on all archs _except_ when we are running on a PowerMac (and this will be checked at runtime and not compile time).
Re: woody boot-floppies
> >well until someone donates an ibook2 to me i can't be sure what the >deal is, all i know is a report from benh that he simply could not get >debian's 2.2.19 to boot his ibook2 period, and i am pretty sure he >hacked around on it for awhile. Heh, well, don't assume to much about me :) I don't think I tried the novideo thing, most of the tests I did were with 2.4 kernels anyway as 2.2.x lacks a few rather important thing to support recent machines properly. Anyway, given the current status of 2.4.x, I think I will take some time next week to backport most of this to 2.2.20 so at least a reliable 2.2.x can be used for people who don't want to fight with the various 2.4.x problems :( Ben.
Re: Need 2.4.9-benh0 snapshot or diff
>i have diffed ben's and Linus' tree and the differences are almost >entirely due to i2o (sound hardware you don't have) and iSeries >(something else you don't have any use for, its some embedded arch i >think). > >penguinppc.org has been running pure Linus since 2.4.8, its currently >on 2.4.12 with no problems whatsoever, and its a newworld G4, with >oldworld your definitly fine with Linus. With a few exceptions... The power management is definitely not up to date in Linus tree, as are a few Mac specific drivers. I would recomment using the Linus tree (or bk _2_4 which is supposed to be very close to linus as it is regulary merged) for desktop machines. bk _2_4_devel is probably a better choice for laptop users as it contains all the power management tweaks. My rsync tree is definitely not something you want to use if you are looking for a stable kernel source :) I keep no version control and occasionally push some very experimental changes. Use it at your own risk. It's purpose is for people to test some experimental stuffs I'm working on, like firewire support, AGP support, etc... Once those things are considered stable enough, I merge them into 2_4_devel, and eventually 2_4 (in this case, I also send patches to Linus for inclusion in the main tree). Ben.
Re: Need 2.4.9-benh0 snapshot or diff
> >yes, i forgot to mention power management. when do you think that >will be stable enough to start sendint to linus and merging with the >stable branch? The problem isn't really stability, but more various tweaks I had to do to non-PPC specific code that will be difficult to merge. I will try to get those in once 2.4.x is considered as "stable" ;) On the other end, I'm working with Patrick Mochel on the new driver model and PM stuff for 2.5 that should "fix" this problem once for all. >> Once those things are considered stable enough, I merge them into >> 2_4_devel, and eventually 2_4 (in this case, I also send patches >> to Linus for inclusion in the main tree). > >do you send them or does paulus? i haven't seen your name in any of >linus' changelogs in quite some time, but paul has been getting stuff >merged quite regularly (though nothing much since .10). I do send some myself occasionally, Linus doesn't like my mailer very much, and tend to forget adding my name to the cset's ;) Ben.
Re: Powerpc (mac-G4) -essentially broken
>All my apps talk to /dev/dsp, or esd (I'm trying to give it up). It's just >things like the KDE stuff which use the sound server. Maybe I should just >disable sound in KDE. Or maybe the problem will disappear after a few >weeks as >a testing deb changes? Well, maybe. You should still fill a bug report against the package. It would be interesting if you could test the sid package though. If neither works, then try recompiling the sound server from upstream latest source base. If you find one that works, then submit a debian bug report giving that info ;) If not then someone need to go fix it. >I don't think the keymap *is* broken. The 3 key has a £-sign on it, and no #. >There is *no* key on the keyboard with a # on it, nor is there a delete >key. I >think I'm using Linux keycodes (yaboot.conf has append="video=ofonly >keyboard_sends_linux_keycodes=1" [or whatever the incantation is] in it) When >prompted about the keyboard for X, I said gb and it seemed to like that. Well, how do you get # in MacOS ? It could be some kind of key combo. For example, on french "Mac" keymaps, the pipe (|) is obtained with cmd-shift-L and isn't actually written on the key. I beleive the X "mac" keymaps are mimmic'ing the MacOS ones there (while beeing a bit broken; I still need to submit my fixed french one ;) Another possibility is to plug a PC keyboard and use a PC keymap. The point with the linux keycodes is that they are the same for PC & Mac kbds allowing you to use either the "Apple" layout with the "mac" keymaps or a standard PC layout with the ordinary PC keymaps. >GPM is not installed, as we really only ever use X and it gave me grief a long >time ago on intel platforms, so I tend to do without it. Should I be running >GPM and feeding the XServer from that? I think I understand how that >works, but >it seemed a bit complicated to me. > >The mouse locks up, but the keyboard is fine. KDE exits cleanly, it seems. >When kdm comes back, I can tab down to Shutdown, and select reboot using the >keyboard, but the mouse is frozen (pointer in the middle of the screen); it's >just that it isn't the Unix way to reboot after each session 8-) I don't know what's up with your mouse :( I haven't experienced this (but I don't use KDE neither). Either an X server issue triggered by KDE or some latent input layer bug ? This will need some debugging. Ben.
Re: audio on G4 Mac
>I have been playing various audio file using Debian PPC Unstable. >I've noticed that the small system speaker is on with my main speakers. >I would like to turn off the small system speaker because it ruins the >sound experience with it's tinny, beaming quality. How do I do this? What model of G4 do you have ? More specifically, what kind of sound chip does it have ? (displayed in dmesg when you insmod the driver). The "tumbler" supports auto-mute of the speaker when the jack is plugged with recent kernel, other chipsets don't implement that feature yet. Ben.
Re: Powerpc (mac-G4) -essentially broken
>I'm not arguing, and I can see that this is a very valid point of view >(kernel as a hardware abstraction layer, supporting only the facilities >the hardware does, and thus avoiding bloating with creaping featureism). > But the alternative view would be that the kernel's sound interface is >there to play sound, regardless of byte order, and as we all know most >of the world has got ints the wrong way around, so it would be splendid >if the kernel could sort things out for us. Obviously this isn't going >to fix the problem of asking for native sending the opposite or vice >versa, but how difficult is it just to byte-reverse things? It's a lot easier to do in userland ;) The sound is DMA'ed directly to the sound chip, the kernel don't touch the samples, at least not in 16 bits mode. >I'm saying this because my next job will have to be building libarts >from source and then trying to fix it. I would rather make a smaller >change to the kernel module to provide both endianess, but it seems you >don't like that. Neither do Linus ;) Ben.
Re: playing DVD on pismo (powerbook)
>hello, >i try to make DVD ( xine, mplayer, or whatever else) works on pismo >(powerbook) system, but the video playback is _really_ slow. >i'm running debian sid on a 2.4.19-pre2 kernel. >ppl from xine project said me my DVD drive is to slow to read DVD : I doubt your problem has anything to do with DVD drive speed. The problem is decoding of the MPEG2 stream. MacOS uses the ATI chip hardware IDCT and Motion Compensation engine, we can't in linux since ATI doesn't provide infos/specs about it. So we have to do 100% software decoding for which your CPU isn't fast enough (well, it _might_ be if someone really understood how to hand optimize the algorithm, but I'm not sure :). On G4 machines, we have some altivec optimisations that make it doable, but that isn't the case on G3s. Ben.
Re: hfs related crashes
> currently im having consistent (but erratic) problems reading from an hfs >partition using kmail. im not sure what the problem is, but quite often when >i try to access a mail folder which is symlinked to the hfs partition, i get >some nice blakc lines at the top of my screen + the system is completely >frozen (no xterm/console or ssh access). > >im using the 2.4.18-benh kernel, with hfs support compiled in (ive also had >the same probelms with hfs as a module) with kmail 1.3.2 (kde 2.2.2) > >any ideas on how to improve this situation?+ The kernel HFS filesytem is buggy. The solution is for someone to maintain & fix it. Ben.
Re: Audio CDs in xmms on ibook2 2001 600Mhz
>> Investigation shows that the size of fragments written to /dev/dsp seems >> to be critical, fragments smaller than about 4096 bytes cause the looping >> hang frequently. Fortunately, there are good games like tuxracer where >> this can be configured. :) > >Interesting... > >> Still, benh and I suspect a driver bug, he has discovered some oddities >> wrt the tumbler. > >That doesn't surprise me :-) The tumbler is odd to begin with :-P >Ben, let me know what you've found when you get a chance... What I have found is mostly cases where the dmasound code would try to write awacs registers on i2s based machines, which means the i2s registers could be garbaged. I'm fixing this in my tree along with making sure i2s is properly configured from 44.1Khz and 16 bits samples. I'm wondering though if the problem could be fifo ping pong between Keylargo and the sound chip, eventually the sound clock provided by KL could be wrong. There are some bits in KeyLargo FCR 1 that can control the clock fed to the sound chip, I'll try to see if those contain sensible values (they are supposed to be set by OF). Ben.
Re: Audio CDs in xmms on ibook2 2001 600Mhz
>Ah, thanks. > >> I'm wondering though if the problem could be fifo ping pong between >> Keylargo and the sound chip, eventually the sound clock provided by >> KL could be wrong. There are some bits in KeyLargo FCR 1 that can >> control the clock fed to the sound chip, I'll try to see if those >> contain sensible values (they are supposed to be set by OF). > >Makes sense. Let me know how it turns out. I'll turn my attention back >to the full-duplex thing :-) I'm not sure it's worth hacking much in the horrible mess that is the current dmasound_pmac. 2.5 is bringing the Alsa driver in which has already been split, I'm wondering if we shouldn't go the same way for what remains of 2.4 lifetime and split dmasound as well. Ben.
Re: Sound on Tanzania, and life with Apple Open Firmware
> Sounds working just great on my Tanzania/4400, I'm just curious. On the >> MB, I see a Crystal chip that looks like it should be sound, but no such >> device shows up on the PCI bus. In fact, I haven't been able to find >> any sign of having a sound device. >> >> But the dmasound driver loads, and it plays music *better than it did in >> it's life as a Macintosh. (???) >> >> Does anyone know how this works? The sound bus comes out of the mac-io ASIC (ohare on your Tanzania). This ASIC contains various things in one PCI device (interrupt controller, sound bus, IDE, etc...). The AWACS chip is connected to that bus. Ben.
Re: Update: USB-ISDN Adaptor for Powerbooks
>I'm afraid we do neither provide precompiled binary files for MAC machines >nor do we release the corresponding source code. > >So: Does anybody have any ISDN adaptor that works with a Linux iBook? >Any experience how to get a BeWan Gazel 128? I wasn't able to find a shop >that sells those in Germany... Bewan gazel works. But you should still bug them about releasing a PPC binary of their lib ;) Ben.
Re: Update: USB-ISDN Adaptor for Powerbooks
>Well, I don't know anything else I could do, except trying to return the >adaptor to my dealer (it doesn't really have the announced Linux support >after all...). But I seriously doubt that AVM will even notice... Well, if enough users complan, who knows... >Regarding the gazel, I've heared from several people that it works, but >I'm still looking for a place to actually buy one. I don't really have to >become a BeWan authorized reseller just to get such an adaptor, do I? > >Wondering about different shades of "Linux Support", The BeWan USB driver is developed by a friend of mine, it's completely supported. The BeWan PCI card need some endian fixes to hcf-pci that may have been merged in the official tree already. Regarding getting a bewan adapter, I don't know. Did you try online vendors ? You can eventually call them and ask who is ditributing the adapter near your location. Ben.
Re: Problems setting time on iBook2
> >My workaround for the time problem is to use ntp and co. > >Apparently, it's possible to have MacOS X use UTC time as well, don't >know how though. Probably by setting the timezone in the PRAM to UTC. I think MacOS X will do just like linux, that is use the PRAM to convert whatever time is in the RTC to UTC, then use it's own unix'ish way to handle time zones internally, thus not touching the PRAM anymore. I haven't tested, but I beleive if the timezone info in PRAM is set to UTC, you can then have both linux and MacOS X use UTC RTC. MacOS 9 is a different story here. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: vlc 0.3.0 and Altivec
>I have an ibook2, 500 MHz. Now, I thought that the G3 didn't have >Altivec, and I am running 2.4.19-pre6-ben0 >from ppckernel.org. > >So, is this vlc wrongly detecting my CPU having Altivec or the kernel not >being correctly compiled ? >I thought I might post here first before troubling the vlc people. It is vlc wrongly detecting your CPU having altivec Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: benh work on quik?
>benh: > >You posted a note about RAM for your 8500, and planning >to do some work on BootX. I wonder if you'd also consider >working on quik. I've done some playing around. Yes sure ! I happily discovered how well quik worked automagically from debian install on this 8500 ;) >I've done some comparing of code between yaboot and quik, and really >very little of it depends on OF. Quik has to rely on a bootblock, I >guess, so first.b is a given. But, it seems to me, once we're out of OF, >that we should be able to make yaboot run. It is the same architecture, >after all. Yes, except a few memory management tweaks and other workarounds for OF bugs. >I tried just substituting yaboot for second.b, that would have been >too easy. But I think almost the same concept should fly. I noticed >the memory map that's set up for second.b doesn't leave enough room >for yaboot (it leaves about 48k and yaboot needs around 160k IIRC) so >I bolluxed up the memory map a bit trying to give it more room - but >I'm obviously way over my head here and it didn't work. I'll give it a look >I guess next best, would be to substitute the applicable parts of >yaboot into quik, or port yaboot to oldworlds (but I don't think >Ethan's into that). I just don't know of any reason why it shouldn't >work in theory at a top level: get booted with quik type bootblock >code, continue with yaboot in all its glory. Yes. >If you're not planning to work on this, could you at least point me >in the right direction so I can continue experimenting? I'll try to hack on this next week-end, I'll let you know. I'm not completely sure yet what is broken, but I do have some clues, I want to fix first.b to be able to load yaboot ELF, though if that ends up bloating it too much, I'll revert to generating a special yaboot binary format that is simpler to load & parse. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: benh work on quik?
> >I'll try to hack on this next week-end, I'll let you know. I'm not >completely sure yet what is broken, but I do have some clues, I want >to fix first.b to be able to load yaboot ELF, though if that ends up >bloating it too much, I'll revert to generating a special yaboot >binary format that is simpler to load & parse. BTW, This leads me to a question. Did any of you actually tried the various OF patches provided by Apple along with Darwin/OSX bootloader and how well/bad they cope with quik ? It would make sense for ybin to be able to install the appropriate OF patch along with first.b/yaboot on oldworld; though the patch themselves would have to be distributed separately for licence reasons. (And that would also make easier for people to eventually write GPLd ones). That would allow more machines to reliably OF boot in the end, which I prefer a lot over BootX for a lot of reasons. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Marc Boucher HCF modem drivers
>I notice that he keeps releasing updates (http://www.mbsi.ca/cnxtlindrv/). >Is there any news on how support for the iBook 600 internal modem support >is coming along? I won't go into how I feel about Apple putting this damn >modem in here in the first place, but how will I be able to tell from this >page if/when the necessary support is added? He will be working on it soon Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SMP Kernel
>Hello, > >it look like I need some ... help, piece of advice or a word of wisdom. > >One PMac 7500 with a 604e is already working as a local squid proxy with >debian GNU/Linux woody. > >Befor that I got a 8500 180MP doing the same job until a disc crash. It >worked with both cpus, but I lost that kernel :-( > >Now after sampling some spare parts for a second PMac 7500 debian GNU/Linux >box, I tried to set up a working MP machine that should use a Asante >100MBit ethernet card. > >Installation and working with woody and kernel 2.2.20 was easy and without >major problems. With dselect I found and installed a kernel-image 2.4.18 >powerpc-smp. And three problems are hunting me now. Here they are: > >Display: >I have an old 16" Apple Display, no multisync. It works great with kernel >2.2.20. Booting with kernel 2.4.18 shows only a flickering display (no >sync). Somewhere I read that the PMac 7500 has a broken OpenFirmware that >need to be patched. Done and no difference. It look like this patch came >from the NetBSD team and there I found that after the patch that >OpenFirmware will sync with 640*400 60HZ!?!?! > >Is this true? Does kernel 2.4.18 only work with multisync monitors? Did you try giving an explicit vmode argument to the kernel ? It's possible that the kernel fails to probe the monitor type. > >Ethernet: >The Asante 10/100 Fast Ethernet card works with kernel 2.2.20. I took one >or two reboots (no display, read the previous point) until I thought about >trrying the old mianboard MACE port. Right! Perhaps this is a bug. > >With dmesg I found that kernel 2.4.18 find the Asante ethernet card (DEC >chip) at first (eth0) and the Mac MACE ethernet mainboard interface as the >second one (eth1). But when I installed woody the kernel 2.2.20 set up the >Apple MACE as eth0 and the Asante Dec chip as eth1. Vice Versa!!! Well, device initialisation order is... random. Sorry, there isn't much to do about this, except maybe having both as modules and only loading the one you need. >"OK" I thought, "change it". I type (without a display) the ifconfig orders >to change the interface. It worked until reboot. I tried kernel arguments >with bootx, no go. I edit the /etc/network/interfaces so that 2 equal >settings for eth0 and eth1 are found -> NO GO. > >The question is: How can I tell kernel 2.4.18 to use the kernel 2.2.20 >interface and network setting? That should work, you should try harder I beleive to find what's going on. I noticed that sometimes, the MACE is fucked up after boot and won't receive/send anything useful. I seems that can also be triggered by some DHCP clients, though I haven't yet found what's wrong. > >SMP: >After installing woody and setting up the base system I installed the >dselect kernel image 2.4.18 powerpc-smp. After I worked around the previous >bugs/features I found that I've got 2 CPUs working (cat /proc/cpuinfo >showed 2). Then I tried to get a better smp kernel with at least one error >less (display or ethernet card). To put it in a nutshell, neither kernel >2.2.20 nor the original or patched kernel 2.4.18 compiled to a working smp >kernel (I used the /boot/config* files as a start for kernel compilation). Well, I can confirm that my current rsync compiles and works SMP as I'm running it on a dual 8500 at home ;) For your display problem, I have a multisync monitor, so it works, I suspect the monitor sensing isn't done properly so we don't sync to some resolution compatible with your 16" display. Try passing video=controlfb:vmode:13 >What's worth. After I tried those smp kernels without success, even the >purged and newly installed kernel image 2.4.18 smp won't work. dmesg says: >entering smp, cpu 1 stuck !!! How do you boot ? quik (OF) or BootX ? If you boot with BootX and your MacOS is more recent than 8.1, you will have problems getting the second CPU to start as it will have been hijacked by MacOS. >What's going wrong? After a new setup from ground the smp kernel image was >working and after trying to compile and use a custom kernel, even the >kernel image is broken? And I set back the P-RAM more then 10 times. > >What's wrong? > > >In the end I might ask some of the gurus: Does it make sense to allow to >change from kernel 2.2 to kernel 2.4 when the hardware isn't recognized the >same way? Wouldn't it be a _very_ good idea to do a woody/kernel-2.2 and a >woody/kernel-2.4 distribution? HW is recognized, at least for my 8500, woody worked out of the box. There may be some rough edges, all we have to do is fix them. >But don't get me wrong. I have the greatest respect and I'm completly >surprised in an absolutly positiv way of the debian/GNU program and the >personal time everyone spend for that. > >Your's >Ralf > > >-- >To UNSUBSCRIBE, email to [EMAIL PROTECTED] >with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAI
Re: Audio Problems on an iBook
>I *still* have not been able to reproduce this despite putting my TiBook >to sleep several times daily. I wish that we could find a foolproof way >of reproducing this so that I can look into it. It happened to me exactly once, despite putting my tibook to sleep several times a day too and that for several monthes now. >> I've not seen it happen in MacOS, but then again, I've probably spent >> less than 6 hours with MacOS running on the bare metal. > > I know that feeling. I only boot to OS-X to update it now and then. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Running powerbook with the lid down
>Rory Campbell-Lange <[EMAIL PROTECTED]> writes: > >> On 25/04/02, Benjamin Herrenschmidt ([EMAIL PROTECTED]) wrote: >> > Note that OS X doesn't support that well neither, as a bit like linux, >> > it globally consumes more power than MacOS 9. >> >> Why is that, Ben? > >Because the machine can't properly sleep? (due to the process >scheduler) > >MacOS doesn't have a process scheduler because it is a co-operative >system. Well, actually, I'm not sure if the reason why it doesn't work in MacOS X is just an Apple bug or if they intentionally disabled the feature because of power consumption. MacOS 9 has some features to slow down or stop the CPU for longer period of times when the machine is idle that what would be possible with a fixed timer preemption scheduler like we have in linux. They have different "idle" modes depending on the user activity, which can be nice in some case, but I beleive a lot of linux users would hate them on servers ;) Finally, in linux, we don't yet have proper code to access the thermostats in the machine, which would be useful to measure if there is really a risk or not by running with the lid closed. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Audio Problems on an iBook
> >To solve this, I'm hoping to finish the DRC and biquad filtering >implementations that I started. I just haven't been able to figure out >which canned filter settings are the best for this hardware yet (I'm NOT >fond of the ones that Apple uses in the Darwin code) and also don't know >how I want to implement turning those features off, if desired (I'm >thinking /proc, but haven't written the code yet). Yes, a /proc entry for setting custom biquad filters would be nice ;) Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SMP for 2.4.18 on duel G4 Mac
> >As it turns out there was a problem with CONFIG_ACORN_PARTITION and >CONFIG_SMP. Linux would compile with CONFIG_ACORN_PARTITION defined >without CONFIG_SMP but when I added CONFIG_SMP I got a link error. Ok, this is an upstream problem (not PPC specific), the ARM maintainers will have to fix that ultimately. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iBook and playing DVDs
>> Doesn't xv support double buffer ? > >Some drivers (including r128 and radeon) do, but that just means that >the current image will be displayed on the next retrace after it has >been transferred to video RAM. Ok, so I beleive we can't blit asynchronously because the source buffer won't be availble to the X server upon exist from putimage ? If this is not that case, that is if X can still tap the source buffer upon exit from put image, it can do async blit transparently pretty easily. In all cases, we would surely benefit some way to block on the interrupt instead of spin looping. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iBook and playing DVDs
>> ATI doesn't recommend that. The refresh rate of the screen is >> high enough that if you display from AGP memory, you'll cause >> a hell lot more throughput on the bus than with a single blit. > >ATI wouldn't likely recommend uncached/guarded or not using >the hardware IDCT either though. uncached/guarded is more or less mandatory on AGP as the HW isn't cache coherent, though we would probably get better throughput using cached mapping and explicit cache flushes. As far as HW IDCT is concerned, well... :) >If this has any chance of getting me 1600x1024 at 24-bit on >my Mac Cube, then I like it. It's good even if the video >isn't full screen or full framerate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 700MHz iBook: ATI Mobility Radeon 7500?
>AFAIK it supports both chips, but I think the panel size is still >hack^K^Krdcoded to 1152x768 on powerpc... Should be properly probed from OF EDID with my latest kernels. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iBook and playing DVDs
>Hey, wait a minute... why guarded? Well, you are right about this, guarded isn't needed though the kernel tends to put guarded along with cache inhibit automatically (it does so in ioremap for example). The main reason I set it currently that I'm still trying to figure out what is causing both r128 and radeon drivers to lockup when using DRI + AGP with Apple chipset, and among the things I suspected was a speculative access issue, but I tend to no longer think it's related. >Tell me where I'm wrong: > >AGP memory is regular RAM on the motherboard. >(at least it isn't device registers) Yes. >Typically an app puts images (bumpmaps, textures, etc.) >in AGP memory. Triangles for 3d rendering also >get written to AGP memory. Yes. >This app is X, or an authorized local client. Yes. >It is not common to have the video card writing >to AGP memory. By default, the r128 and radeon DRI drivers to write to AGP memory the ring readptr, but doing so seem to be broken on some HW (UniNorth 1.0.x and some ia64 bridges don't deal with that properly) >If the video card does write to memory, X can >ensure that this doesn't happen to memory that >the user is busy writing to. Currently, I tweaked r128 to write using normal PCI cycles to a separate page of memory only holding that ring pointer, and I hacked radeon to not write, but instead have the driver read that pointer from the card MMIO registers. This didn't help fixing the lockup though. >It is not common for the for the user to read AGP memory. You don't know. If it's cacheable, writing a byte will cause a CPU load of the entire cacheline for example. >If the user does read from AGP memory, the X server >could flush some cache lines before telling the user >that the memory has been updated. (PowerPC uses a >physical cache, not a virtual cache) Well, +/- On radeon+DRI, we could do a flush pass on the indirect buffers when they get passed to the kernel driver. >The motherboard chipset will walk some sort of page table >when the video card tries to access AGP memory. This is >kept coherent by a Linux kernel DRI/DRM/AGP driver. The uninorth driver does explicit flush of this page table after modifying, I don't map it uncacheable. >Aside from X itself, ordering isn't going to matter. >User apps won't be trying to atomicly update data >structures as viewed from the video card. X might >do this. > >It wouldn't be insane to update X to include all >the necessary cache-related instructions. Actually, not X, but the DRM kernel driver. >User apps need caching off by default, since trying to >update all the apps would be insane. > >Unless user code will write to AGP memory on one >processor and read or write on another processor, >the M bit (Memory Coherency Attribute) can be >cleared. It's pointless for the CPU to waste bus >cycles trying to be coherent, since the video card >will not cooperate. All non-SMP systems should >map the AGP memory with coherency disabled. I'm not too sure about that. What about one CPU writing half a cache line of the ring buffer in AGP memory, and another CPU writing the other half ? >No existing PowerPC will do unrequested prefetching >across page boundries, or this is easily avoided >by not using memory adjacent to the boundry >between AGP memory and non-AGP memory. That isn't a problem, though I'm not sure about your statement that they won't do unrequested prefetching. Do you have some pointers to the docs ? >If apps would at least avoid reading stuff written >by the video card, write-through cached would be OK. >Apps that read AGP memory are uncommon enough that >fixing all of them would be feasible. I think we can use full caching (copyback) without too much problems. In the r128 case, we'll have to flush from the X server as it's directly writing to the ring (and maybe from the mesa driver as well). On radeon, it's all done via indirect buffers and those get passed to the kernel driver before beeing inserted in the ring. So we can definitely improve the throughput by letting it be cacheable. The main reason I didn't work on this yet is that I want the driver to be stable first to avoid possibly mixing problems. Currently, I haven't managed to figure out what is causing the card lockups when AGP is used. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iBook and playing DVDs
>What about a mixed approach to avoid unnecessary bus traffic: try to read >the ring head pointer from memory, and if after a timeout the free ring space >still doesn't seem to be large enough, read it directly from the register. >This could hurt performance badly if the memory copy is often outdated though. Well, let's first make it stable... > >> >If apps would at least avoid reading stuff written >> >by the video card, write-through cached would be OK. >> >Apps that read AGP memory are uncommon enough that >> >fixing all of them would be feasible. >> >> I think we can use full caching (copyback) without too much >> problems. In the r128 case, we'll have to flush from the X server >> as it's directly writing to the ring (and maybe from the mesa driver >> as well). On radeon, it's all done via indirect buffers and those >> get passed to the kernel driver before beeing inserted in the ring. > >Where is r128 different than radeon in this respect? The last time I looked at r128, it wrote to the ring directly iirc, while radeon on wrote to indirect buffers, the kernel putting them in the ring. This may have changed though. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iBook and playing DVDs
>On Wed, 2002-05-22 at 21:48, [EMAIL PROTECTED] wrote: >> >What about a mixed approach to avoid unnecessary bus traffic: try to read >> >the ring head pointer from memory, and if after a timeout the free >ring space >> >still doesn't seem to be large enough, read it directly from the register. >> >This could hurt performance badly if the memory copy is often outdated >> though. >> >> Well, let's first make it stable... > >Good idea. :) Do you agree with Albert's analysis? Have you tried with >caching enabled yet? Albert analysis makes sense, though I tried a different approach which was to set the Guarded bit on the BAT mapping. Well, anyway, I'll do some experiments with that again when I have less pressure from work, I can at least try to find some more infos about what's going on in the card when the CCE stops. > >> >> >If apps would at least avoid reading stuff written >> >> >by the video card, write-through cached would be OK. >> >> >Apps that read AGP memory are uncommon enough that >> >> >fixing all of them would be feasible. >> >> >> >> I think we can use full caching (copyback) without too much >> >> problems. In the r128 case, we'll have to flush from the X server >> >> as it's directly writing to the ring (and maybe from the mesa driver >> >> as well). On radeon, it's all done via indirect buffers and those >> >> get passed to the kernel driver before beeing inserted in the ring. >> > >> >Where is r128 different than radeon in this respect? >> >> The last time I looked at r128, it wrote to the ring directly iirc, >> while radeon on wrote to indirect buffers, the kernel putting them >> in the ring. This may have changed though. > >I'm pretty sure only the kernel ever had access to the ring in both >drivers (the only exception I know of were the ati-5-0-[01] branches in >DRI CVS, but they were never merged into the trunk, let alone an XFree86 >release). Ok, my memory may be failing here ;) Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TiBook DVI report/problems
>Ok, I've got my Powerbook G4 DVI (i.e. powerbook rev C, i.e. powerbook >w/radeon 7500 M7, etc) pretty much setup how I like it. A couple of people >have asked me to give a rundown of what works/what doesn't so here it goes: > >-X4.1: works great, using the fbdev & radeonfb. Gonna try out Michael's > 4.2 binaries this weekend. >-Sound: works great, even though apple rev'd the hardware >-USB: works fine too. >-Power Management: mostly functional, /dev/apm_bios works, wmapm works, > Pmud mostly works. The powerbook will sleep OK, but it won't wake up. > (anybody know how to troubleshoot this?) >-Screen brightness: works, but the keys are reversed (f1 makes the screen > brighter, f2 makes it dimmer). > >That's it, everything works pretty well, 'cept sleeping, anybody know >why? Probably related to the video chip sleep code. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [xine-user] [ANN] PowerPC Assembly Patch
> We can also look into getting an extra version of memcpy that > makes the transfers with floating point registers as some > people suggested on the Debian PowerPC mailing list. > > People there said that using floating point registers (which > are 64 bits large) instead of general purpose registers (32 > bits each) may improve things. It will, but you have to be properly aligned. Another thing you could do is make an altivec memcpy. I saw there is one in the latest VideoLAN CVS you can grab, though I don't know if it handle misaligned transfers (the Altivec can deal with those more easily than the FPU, though it's always better to have things aligned, in the altivec case the alignement boundary is 4 words (128 bits)). >> I'd like to know how much it helps PPC users, so keep this list up >> to date with the results. (Also, if my patch breaks other >> platforms...) It gave my Mac laptop the little boost it needed to >> play some media I have. > > Well, with the faster memcpy and with XFree86 4.2.0 (with DMA > enabled), I can watch a DVD here with linearblend > deinterlacing (coded in C) enabled and there are about 15% of > frames skipped, which while still not perfect, is quite an > improvement in face of the situation some weeks ago. With an encrypted DVD, I also noticed the kernel abuse PIO transfers instead of DMA. I think there's a patch floating around to improve that. Also make sure you are using unmask irq on your DVD (hdparm -u1 /dev/hdc) > BTW, I am using gcc-3.0 to compile xine-libs and I added some > extra options to the configure script (-mfused-madd, > -mcpu=750, -mtune=750, -O9). > > The next points of improvement (which may not be as immediate > as using the memcpy being discussion) may be coding the idct, > motion compensation and deinterlacing in assembly also. There are already altivec implementations, but no ordinary PPC asm ones. One other big killer on PPC is byte access. Look at the bitstream decoding, if you manage to do only 32 bits aligned loads from memory, then do the splitting in registers, you may actually improve perfs slightly. > I guess that I'll heave to learn a bit more before I can get > to these, but with the help of other people, things could go > faster. > >> Just so you know, the methods I used are from the linux kernel >> version 2.4.18 (arch/ppc/lib/string.S) > > Yes, that's what I tried in my earlier message, but I wasn't > as succesful as you were. > > Your patch had a problem, though and I had to apply a part of > it by hand. You might perhaps want to remake it and send to > the xine developers so that it can be included for xine > release 0.9.10, which should be near. > >> Andrew Patrikalakis > > > Thanks for your help, Roger... > >-- >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > >-- >To UNSUBSCRIBE, email to [EMAIL PROTECTED] >with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [xine-user] [ANN] PowerPC Assembly Patch
BTW. Another place where you can get improved perfs is improving the memcpy's used to blit the Xv source image to the DMA buffers in R128DMA(). Currently, if using PCIGART, the target DMA buffers are cacheable. When using AGP, though, they aren't. In both cases, using FP registers to do the blit should improve things. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new iBook 700 LCD / ohci1394 driver.
>sing Ben's kernel 2.4.19-pre8-ben0 I didn't seem to be able to get the >ieee1394 driver to recognise the iBook "target". I had the relevant modules >loaded (I think) -- 1394, OHCI1394, SPB2, SCSI, SCSI hard disk -- but >repeatedly plugging the target in produced no response on the old iBook (no >kernel messages) and then rmmod'ing the ohci1394 module caused a kernel >panic. Ooops. > >I guess the ohci1394 driver doesn't like the iBook hardware yet? > >What a shame, this was going to be a lovely method to do a super-quick >super-easy installation. It should support it, but it definitely doesn't support sleep, so beware not to put the machine to sleep when ohci1394 is loaded. If it still doesn't work with my latest kernel, please send me a dmesg log after doing modprobe ohci1394 and then plugging the remote machine. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
