Menu
▾
▴
linux-fbdev-devel
|
From: Sven <lu...@dp...> - 2002-01-08 13:40:52
|
Hello, ... Saturday, i upgraded my box from a K6-2 on an ali chipset wich i gave my little brother to a duron 1000 on a sis 735 chipset, rebooted the same 2.4.17 kernel i have been using without problem with pm3fb, and ... no more pm3fb, only a black screen with some very dark grey garbage. X launched ok though, so i rebuilt the kernel switching the ali agpgart and ide modules with the sis ones, and maybe some other such stuff, but no changes. Romain, ... Do you know if pm3fb is still supposed to work ok with 2.4.17 ? I guess yes, because it worked before. I did not yet try vgafb, will do this evening. Does someone have any idea on why pm3fb could be affected by this mainboard change ? Maybe somethign related to the AGP version or something such (the old board was AGPx2 only, while the new one supports AGP 2.0 and x4). All messages from the kernel were ok, as if pm3fb loaded nicely. Romain, do you plan to some day have pm3fb included into the kernel, or will this only happen with ruby and the 2.5/2.6 tree ? Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2002-01-08 13:51:25
|
Sven wrote: > Romain, ... Do you know if pm3fb is still supposed to work ok with 2.4.17 ? I > guess yes, because it worked before. I did not yet try vgafb, will do this > evening. I don't know of any problem... Is it the same pm3fb, or did you upgrade in the meantime ? Maybe I broke something in 1.4.10 or 1.4.9... Does option 'printtimings' works, and if yes, what is reported in the kernel log ? Main change in 1.4.10 is the SDRAM bug, I didn't try it, only added the XFree86 workaround... Did you try changing the resolution and/or color depth ? > Romain, do you plan to some day have pm3fb included into the kernel, or will > this only happen with ruby and the 2.5/2.6 tree ? I might try getting it integrated in 2.4, as I'm short on time and the Ruby version is on ice (that, and the fact I bought a laptop with a Radeon in it :-) -- DOLBEAU Romain | You won't break me ENS Cachan / Ker Lann | You won't make me Thesard IRISA / CAPS | You won't take me dol...@cl... | -- Judas Priest, 'Blood Red Skies' |
|
From: Sven <lu...@dp...> - 2002-01-08 13:55:22
|
On Tue, Jan 08, 2002 at 02:50:34PM +0100, Romain Dolbeau wrote: > Sven wrote: > > > Romain, ... Do you know if pm3fb is still supposed to work ok with 2.4.17 ? I > > guess yes, because it worked before. I did not yet try vgafb, will do this > > evening. > > I don't know of any problem... Is it the same pm3fb, or did you upgrade > in the meantime ? Maybe I broke something in 1.4.10 or 1.4.9... Well, it worked fine with 2.4.17 and the older board, so i guess it has nothing to do with it. I guess it is something related with the agp bus, i see no other reason. > Does option 'printtimings' works, and if yes, what is reported > in the kernel log ? Main change in 1.4.10 is the SDRAM bug, > I didn't try it, only added the XFree86 workaround... Will try. > Did you try changing the resolution and/or color depth ? Well, i did try fbset 640x480, but since i could not see any output, i don't believe it worked, but maybe i mistyped something. > > Romain, do you plan to some day have pm3fb included into the kernel, or will > > this only happen with ruby and the 2.5/2.6 tree ? > > I might try getting it integrated in 2.4, as I'm short on time > and the Ruby version is on ice (that, and the fact I bought > a laptop with a Radeon in it :-) mmm, nice, i suppose it is one of those new powerbooks, isn't it ? I almost bought on of those also, do they work fine for you ? Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2002-01-08 14:00:21
|
Sven wrote: > Well, i did try fbset 640x480, but since i could not see any output, i don't > believe it worked, but maybe i mistyped something. Try using boot-time option, if possible (the theory is that is should'nt matter, but who knows ? :-) > mmm, nice, i suppose it is one of those new powerbooks, isn't it ? Yes. 667 TiBook. Nice machine. Of course now I'm broke :-/ > I almost bought on of those also, do they work fine for you ? Very nice, but there's not much point in running Linux, as MacOS X does everything fine (except that Aqua is really slow... nice, but sloooow :-( ) I managed to have both a FB console display and X, thanks to the hard work of other, so it's very usable even now with linux. -- DOLBEAU Romain | ENS Cachan / Ker Lann | l'histoire est entierement vraie, puisque Thesard IRISA / CAPS | je l'ai imaginee d'un bout a l'autre dol...@cl... | -- Boris Vian |
|
From: Sven <lu...@dp...> - 2002-01-08 14:03:30
|
On Tue, Jan 08, 2002 at 03:00:12PM +0100, Romain Dolbeau wrote: > Sven wrote: > > > Well, i did try fbset 640x480, but since i could not see any output, i don't > > believe it worked, but maybe i mistyped something. > > Try using boot-time option, if possible (the theory is > that is should'nt matter, but who knows ? :-) Ok will try, that and vgafb, Expect my report tommorow. Friendly, Sven Luther |
|
From: Sven <lu...@dp...> - 2002-01-16 15:39:21
|
On Tue, Jan 08, 2002 at 03:00:12PM +0100, Romain Dolbeau wrote: > Sven wrote: > > > Well, i did try fbset 640x480, but since i could not see any output, i don't > > believe it worked, but maybe i mistyped something. > > Try using boot-time option, if possible (the theory is > that is should'nt matter, but who knows ? :-) Mmm, a bit more looking at this and i found out that pm3fb worked, but was displaying on the second head, ... Apparently this new motherboard i have somehow inverts both heads or something such. I don't really understand what happens here, but adding an off:0: did make the console appear on the first head again. (BTW, what hinted me to this is the fact that pm3fb was reporting Appian J2000 head 2, so pm3fb can recognize the correct head number, just doesn't use it to attribute it to the fbs.) BTW, is ruby supposed to work ? I compiled yesterday a 2.5.1 kernel + ruby, and after booting into it, it hangs immediately at the begining (4-5th line of the kernel log). 2.5.2 + vesafb but no ruby works fine though. Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2002-01-16 16:10:38
|
Sven wrote: > I don't really understand what happens here, but adding an off:0: did make the > console appear on the first head again. (BTW, what hinted me to this is the > fact that pm3fb was reporting Appian J2000 head 2, so pm3fb can recognize the > correct head number, just doesn't use it to attribute it to the fbs.) No, fb are registered in the order they are found, i.e. the order of the "pci_find_device()" function. I have no idea how this one behave with regards to motherboard. You should be able to use the "pciid" option to put things back in order. i.e. "pciid:0:1:0:1,pciid:1:1:0:2" (assuming pci bus & device number are 1 & 0) *should* restore the old behavior. The name is not used at all, it's only to make the user feel better, with the board name in dmesg ;-) Seriously, it's only used to try to get proper timings for the memory. > BTW, is ruby supposed to work ? I compiled yesterday a 2.5.1 kernel + ruby, > and after booting into it, it hangs immediately at the begining (4-5th line of > the kernel log). 2.5.2 + vesafb but no ruby works fine though. No, it's not. I never managed to get Ruby working on my box, so I can't even try pm3fb/ruby. When ruby start working OK on PPC, I might try to make pm3fb works in it, if I find the time. -- DOLBEAU Romain | The Gods made Heavy Metal ENS Cachan / Ker Lann | and it's never gonna die Thesard IRISA / CAPS | -- Manowar, dol...@cl... | 'The Gods made Heavy Metal' |
|
From: Sven <lu...@dp...> - 2002-01-16 16:29:30
|
On Wed, Jan 16, 2002 at 05:10:04PM +0100, Romain Dolbeau wrote: > Sven wrote: > > > I don't really understand what happens here, but adding an off:0: did make the > > console appear on the first head again. (BTW, what hinted me to this is the > > fact that pm3fb was reporting Appian J2000 head 2, so pm3fb can recognize the > > correct head number, just doesn't use it to attribute it to the fbs.) > > No, fb are registered in the order they are found, i.e. the order > of the "pci_find_device()" function. I have no idea how this > one behave with regards to motherboard. Ok, i suppose pci_find_device does things wrong fro the ECS K7s5a motherboard, is this something i should take elsewhere ? But then, both X and pm3fb identify the right chip as the first one. > You should be able to use the "pciid" option to put things back > in order. i.e. "pciid:0:1:0:1,pciid:1:1:0:2" (assuming pci bus > & device number are 1 & 0) *should* restore the old behavior. > > The name is not used at all, it's only to make the user > feel better, with the board name in dmesg ;-) Seriously, > it's only used to try to get proper timings for the memory. Ah, ok, ... > > BTW, is ruby supposed to work ? I compiled yesterday a 2.5.1 kernel + ruby, > > and after booting into it, it hangs immediately at the begining (4-5th line of > > the kernel log). 2.5.2 + vesafb but no ruby works fine though. > > No, it's not. I never managed to get Ruby working on my box, > so I can't even try pm3fb/ruby. When ruby start working OK > on PPC, I might try to make pm3fb works in it, if I find > the time. mmm, ... I hope you will get the time for it, ... I could do it, but don't have time also for it right now. Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2002-01-16 16:36:18
|
Sven wrote: > Ok, i suppose pci_find_device does things wrong fro the ECS K7s5a motherboard, > is this something i should take elsewhere ? Well, I don't think the behavior is clearly defined, so it's probably not a bug to return the PCI device in (seemingly) random order. pm3fb has the 'pciid' trick, so a workaround exist... -- DOLBEAU Romain | You won't break me ENS Cachan / Ker Lann | You won't make me Thesard IRISA / CAPS | You won't take me dol...@cl... | -- Judas Priest, 'Blood Red Skies' |
|
From: Sven <lu...@dp...> - 2002-01-16 16:42:07
|
On Wed, Jan 16, 2002 at 05:28:40PM +0100, Romain Dolbeau wrote: > Sven wrote: > > > Ok, i suppose pci_find_device does things wrong fro the ECS K7s5a motherboard, > > is this something i should take elsewhere ? > > Well, I don't think the behavior is clearly defined, so > it's probably not a bug to return the PCI device > in (seemingly) random order. pm3fb has the 'pciid' > trick, so a workaround exist... But, ... Since you are able to get the correct order (as the message proves) it could be possible to re-order it accordyingly ? Or does it causes big problems to do such ? Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2002-01-16 16:53:40
|
Sven wrote: > Since you are able to get the correct order (as the message proves) it could > be possible to re-order it accordyingly ? The head number is simply the same as the PCI function number ;-) I could try to add code to sort the chip according to the function number, but that code would only be useful for multi-head boards on some weirds mobo/kernel combinations... Would that really be useful ? And that would only sort heads on a board, not boards, as you can't guess which PCI bus/device should be the first head... Thinking of it, one could even build a board with the first head on the highest-number function... Honestly, if the 'pciid' trick works for you, I don't think I'll add the sorting. It would be better to 'fix' pci_find_device to get reliable/consistent behavior IMHO. -- DOLBEAU Romain | Who made you God to say ENS Cachan / Ker Lann | "I'll take your life from you!" Thesard IRISA / CAPS | -- Metallica, dol...@cl... | 'Ride the Lightning' |
|
From: Sven <lu...@dp...> - 2002-01-16 16:58:00
|
On Wed, Jan 16, 2002 at 05:53:28PM +0100, Romain Dolbeau wrote: > Sven wrote: > > > Since you are able to get the correct order (as the message proves) it could > > be possible to re-order it accordyingly ? > > The head number is simply the same as the PCI function > number ;-) Ok, i was just asking anyway. Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2002-01-16 17:01:35
|
Sven wrote: > Ok, i was just asking anyway. On second thought, it wouldn't be necessary to sort : during the auto-allocating, I only need to add not the first board, but the board with the same Bus/Device and lowest function number. Could be done in the same loop, only in the end instead of the middle. OTOH, it 'pciid' works...... ;-) ;-) ;-) -- DOLBEAU Romain | Brothers of Metal will always be there ENS Cachan / Ker Lann | Standing together with hands in the air Thesard IRISA / CAPS | -- Manowar, dol...@cl... | 'Brothers of Metal' |
|
From: Geert U. <ge...@li...> - 2002-01-08 14:06:49
|
On Tue, 8 Jan 2002, Sven wrote:
> Saturday, i upgraded my box from a K6-2 on an ali chipset wich i gave my
> little brother to a duron 1000 on a sis 735 chipset, rebooted the same 2.4.17
> kernel i have been using without problem with pm3fb, and ... no more pm3fb,
> only a black screen with some very dark grey garbage. X launched ok though, so
> i rebuilt the kernel switching the ali agpgart and ide modules with the sis
> ones, and maybe some other such stuff, but no changes.
Dumb question, but does the SIS have a builtin graphics chip?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Sven <lu...@dp...> - 2002-01-08 14:11:06
|
On Tue, Jan 08, 2002 at 03:06:07PM +0100, Geert Uytterhoeven wrote: > On Tue, 8 Jan 2002, Sven wrote: > > Saturday, i upgraded my box from a K6-2 on an ali chipset wich i gave my > > little brother to a duron 1000 on a sis 735 chipset, rebooted the same 2.4.17 > > kernel i have been using without problem with pm3fb, and ... no more pm3fb, > > only a black screen with some very dark grey garbage. X launched ok though, so > > i rebuilt the kernel switching the ali agpgart and ide modules with the sis > > ones, and maybe some other such stuff, but no changes. > > Dumb question, but does the SIS have a builtin graphics chip? No, it does not, ... (only the sys xx0 have, not the xx5 chips). X works fine trough. Will provide more debug info tommorow ... Friendly, Sven LUther |
|
From: Ani J. <aj...@sh...> - 2002-01-09 02:15:18
|
On Tue, 8 Jan 2002, Sven wrote: > X works fine trough. Is it because X is softbooting the card? Try removing the int10 calls from the X driver and see if it still works, perhaps that could be it. ani |
|
From: Sven <lu...@dp...> - 2002-01-09 09:39:32
|
On Tue, Jan 08, 2002 at 06:24:07PM -0800, Ani Joshi wrote: > > > On Tue, 8 Jan 2002, Sven wrote: > > > X works fine trough. > > > Is it because X is softbooting the card? Try removing the int10 calls > from the X driver and see if it still works, perhaps that could be it. No, X is not softbooting the card, at least i don't remember so (the bios is broken, and the driver is hand setting the correct parameters (i did write the code after all, so i guess that is what happens, unless the driver did change much since last time i looked at it). Anyway, i will try launching X on the second head, which is not initialized by the bios at all (that's why we had to sdet it up by hand, because the box would hang if we access the uninitialized second pm3 on the board). Friendly, Sven LUther |
|
From: Sven <lu...@dp...> - 2002-01-09 15:09:44
|
On Tue, Jan 08, 2002 at 06:24:07PM -0800, Ani Joshi wrote: > > > On Tue, 8 Jan 2002, Sven wrote: > > > X works fine trough. > > > Is it because X is softbooting the card? Try removing the int10 calls > from the X driver and see if it still works, perhaps that could be it. Nope, it works like a charm on the second head also, for which the cards bios has no information whatsoever. Friendly, Sven Luther |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X