Re: fc-al and A5000
On Tue, 15 Mar 2005 01:00:40 -0500 Morten Pedersen <[EMAIL PROTECTED]> wrote: > does anyone know where to find some information or know how to make my > E4500 talk to my A5000? Unfortunately, you are currently out of luck. The SBUS fc drivers are in a very poor state and don't work for most people. Ben Collins is trying to get the SOC/SOCAL driver working with his array on his E4500. He'll certainly post results if he makes any progress. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
fc-al and A5000
i have an E4500 with a Sbus i/o card. it has 2 GBICs in the slots in the i/o card. i also have some JNI fc-al cards. i also have an A5000 fc-al disk array. does anyone know where to find some information or know how to make my E4500 talk to my A5000? i can talk to the A5000 with my E450 with an QLogic 2100F PCI card. but my E4500 doesn't have a PCI i/o card. i have Debian Sarge. 2.6.9 kernel on both. thanks morten -- no no, I'm not insane. I just have a creative view on reality. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
In line with the subject of porting / obsolescence, I should mention that some not terribly old UltraSPARC systems (my Ultra 10 for example) are not even supported by Sun in Solaris 10. If we quit supporting these, I think they will just quit working. --- Martin <[EMAIL PROTECTED]> wrote: > > > We project that applying these rules for etch will reduce the set > of > > > candidate architectures from 11 to approximately 4 (i386, > powerpc, ia64 > > > and amd64 -- which will be added after sarge's release when > mirror space > > > > no sparc here. > > > > After speaking to Andreas Barth, asking, why sparc might become > SCC, he > > pointed my to the last release update where it says: > > > > | It's for this reason that all architectures are > > | required to be synced to the same kernel version for sarge, but > even so, > > | more per-architecture kernel help is needed, particularly for the > sparc > > | and the arm port. > > > > So we seem to have a lack of sparc kernel hackers/developers. > > I myself are using Debian on sparc very much, but do not have the > > knowledge with sparc kernels to help here. > I know a little and would be willing to help if it meant that sparc > would stay a 'first class citizen'. I don't have much time but I > suspect that a little time given to helping Debian/SPARC would be > better > than having to port everything I run to a different distro / UNIX > just > to have consistancy. > > > The only thing i could do here is testing, testing, testing... > > > > > - 5 developers who will use or work on the port must send in > > > signed requests for its addition > > > > > > - the port must demonstrate that they have at least 50 users > > > > That should be possible somehow. > Guess so. > > Is there anyone 'in charge' of the Debian/sparc port or anyone > co-ordinating the fight to keep Debian/sparc a live port? > > Cheers, > - Martin > > -- > Martin > [EMAIL PROTECTED] > "Seasons change, things come to pass" > > > -- > 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: SunBlade D-I problems
On Mon, 14 Mar 2005, David S. Miller wrote: How exactly is the SBUS device traversal performed? Using /proc/openprom or /dev/openprom tree walking? It uses /dev/openprom, since we only provide /proc/openprom support as a module, so it might not be available. If that is the kind of method used, there are so many different paths you have to try in order to get at all the SBUS bus roots correctly. In particular, on a machine like Ben's E4500, there are probably 4 or so SBUS roots in his machine. Ok, when me and joshk hacked it together, we did not consider such possibilities. By looking at the code I see it looks either for the sbus node in the root of the prom tree (this is a sparc64 fix which was introduced by joshk in August) or iommu->sbus (which works for sparc32, I believe). There are examples in the prtconf sources in the sparc-utils package of what the device tree layouts look like. I'll look at those. If all the information is there, it should not be too hard to fix. Maybe it makes sense just to walk the complete tree looking for sbus_nodes? Perhaps someone else on the list can provide the prtconf output for E4500? Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SunBlade D-I problems
On Mon, 14 Mar 2005 21:51:48 -0500 (EST) Jurij Smakov <[EMAIL PROTECTED]> wrote: > After discussing it with Joshua Kwan, I came to believe that this is just > another incarnation of the CMD646 problem. He had quite a lot of troubles > trying make it work as a module, in the end it was just compiled in > 2.4.27, which took care of the problem. The same "solution" can be used > for ALI, but it would be nice to get to the root of it. > Autoprobing for SBUS devices has been included in discover1 for quite some > time now. And it works nicely with the recent (pre-RC3) installer images, > I have tested it myself just a few days ago on an Ultra 1. How exactly is the SBUS device traversal performed? Using /proc/openprom or /dev/openprom tree walking? If that is the kind of method used, there are so many different paths you have to try in order to get at all the SBUS bus roots correctly. In particular, on a machine like Ben's E4500, there are probably 4 or so SBUS roots in his machine. There are examples in the prtconf sources in the sparc-utils package of what the device tree layouts look like. In hindsight I should have provided some /proc or /sys based SBUS device tree. Eventually I'll code up something like that so people don't have to poke around the firmware device tree for SBUS probing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unofficial 2.6.11 kernel-images available for sparc
Re your keyboard problem, dpkg-reconfigure console-data and select an i386 keyboard layout appropriate to the language of your keyboard. When you run 2.6.xx you must use a 386 layout because the kernel converts the scancodes to 386. When running 2.4.xx you must use a SPARC layout because codes are not converted. HTH! --- Petr <[EMAIL PROTECTED]> wrote: > > > Hi Peter, > > > > In the output you've provided I do not see any hardware detection > program > > (such as discover1) running at boot time. It looks like you have > chosen > > not to use it, but to list the required modules in /etc/modules, so > that > > they are loaded at boot time. In that case in order for the network > card > > to be detected you have to manually add it to the this file (the > name of > > the module is sunhme). It also tries to load modules audio and > cs4231, > > which are not present, you might want to replace these two with > > snd-sun-cs4231. In general, it is quite useful to have discover1 > > installed, as it will take care of loading all necessary modules > > automatically. > > Hi Jurij, > > Thanks for your advice. After adding sunhme to /etc/modules the > happymeal is now working. I still cannot start X or use the keyboard, > but now I can login with ssh. I also have installed discover1. > > > Regards, > Peter > > > -- > 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: SunBlade D-I problems
On Mon, 14 Mar 2005 22:21:53 -0500 Joey Hess <[EMAIL PROTECTED]> wrote: > Yes, but I didn't realize that it was probably a non-bug. Do you think I > ought to revert that then? I think so, just autoloading modules to work around incorrect SBUS module loading isn't such a good idea. > Ben didn't mention in #299074 what version of d-i he used, but it seems > unlikely that it predated rc2, which should have included that change. I've pinged Ben under seperate cover, asking him to provide this information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SunBlade D-I problems
Jurij Smakov wrote: > >>[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299074 > > > >He lists the exact way to solve the problem, which is that > >SBUS driver modules don't get loaded properly, and that > >by autoloading the modules he listed the problem can be worked > >around. > > > >It looks to me like there is an autoprobing and automatic > >module loading mechanism for PCI devices, and there is not > >one for SBUS devices. > > Autoprobing for SBUS devices has been included in discover1 for quite some > time now. And it works nicely with the recent (pre-RC3) installer images, > I have tested it myself just a few days ago on an Ultra 1. Unfortunately, > the submitter does not mention the version of the installer he used... > Anyway, as I was writing this message, the CIA bot reported that Joey Hess > has made a commit forcing the loading of sunbmac, sunhme and esp modules > to close this bug :-). Yes, but I didn't realize that it was probably a non-bug. Do you think I ought to revert that then? I guess the thing that's worrying me is that the last recorded discover1 change for sbus was this: discover1 (1.6.6) unstable; urgency=high * Joshua Kwan - Fix broken sbus detection on sparc64. -- Joshua Kwan <[EMAIL PROTECTED]> Thu, 26 Aug 2004 22:25:31 -0700 Ben didn't mention in #299074 what version of d-i he used, but it seems unlikely that it predated rc2, which should have included that change. -- see shy jo signature.asc Description: Digital signature
Re: SunBlade D-I problems
On Mon, 14 Mar 2005, David S. Miller wrote: The IDE problem is weird. There are two possibilities: 1) The ALI driver doesn't work modular on his box for some reason. 2) Some patch in the debian kernel tree causes it to break. He does state that building a vanilla 2.4.27 with the ALI driver built statically makes it work. I kind of remember this report for some reason. Perhaps some other device took over the IDE ports or something weird like that, which makes modular IDE driver not work. Can we get this reporter to retry with current CDROM images? If it still fails, I'll pull out my SB100 and help debug. After discussing it with Joshua Kwan, I came to believe that this is just another incarnation of the CMD646 problem. He had quite a lot of troubles trying make it work as a module, in the end it was just compiled in 2.4.27, which took care of the problem. The same "solution" can be used for ALI, but it would be nice to get to the root of it. I have looked at the BK tree at some point and it looks like none of the relevant IDE and ALI driver files in 2.4.27 were touched for a long time. There are some ide-related Debian patches, which may be relevant to this problem. If you Dave can reproduce it on his machine, it would be great. [2] http://lists.debian.org/debian-boot/2005/03/msg00249.html This says that current images work and no longer have the problem. There is also #299074 [3], but that is probably unrelated. [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299074 He lists the exact way to solve the problem, which is that SBUS driver modules don't get loaded properly, and that by autoloading the modules he listed the problem can be worked around. It looks to me like there is an autoprobing and automatic module loading mechanism for PCI devices, and there is not one for SBUS devices. Autoprobing for SBUS devices has been included in discover1 for quite some time now. And it works nicely with the recent (pre-RC3) installer images, I have tested it myself just a few days ago on an Ultra 1. Unfortunately, the submitter does not mention the version of the installer he used... Anyway, as I was writing this message, the CIA bot reported that Joey Hess has made a commit forcing the loading of sunbmac, sunhme and esp modules to close this bug :-). Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SunBlade D-I problems (was: Bits (Nybbles?) from the Vancouver release team meeting)
On Tue, 15 Mar 2005 00:07:28 +0100 Frans Pop <[EMAIL PROTECTED]> wrote: > See installation-report #298927 in BTS [1]. Also this [2] thread on > d-boot. > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298927 Current images have the tg3 bug fix he talks about. The IDE problem is weird. There are two possibilities: 1) The ALI driver doesn't work modular on his box for some reason. 2) Some patch in the debian kernel tree causes it to break. He does state that building a vanilla 2.4.27 with the ALI driver built statically makes it work. I kind of remember this report for some reason. Perhaps some other device took over the IDE ports or something weird like that, which makes modular IDE driver not work. Can we get this reporter to retry with current CDROM images? If it still fails, I'll pull out my SB100 and help debug. > [2] http://lists.debian.org/debian-boot/2005/03/msg00249.html This says that current images work and no longer have the problem. > There is also #299074 [3], but that is probably unrelated. > > [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299074 He lists the exact way to solve the problem, which is that SBUS driver modules don't get loaded properly, and that by autoloading the modules he listed the problem can be worked around. It looks to me like there is an autoprobing and automatic module loading mechanism for PCI devices, and there is not one for SBUS devices. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: AtyFB in 2.6.10, still not perfect
On Mon, 14 Mar 2005 23:50:02 +0100 Luigi Gangitano <[EMAIL PROTECTED]> wrote: > Hi all, > I've just upgraded to the latest kernel-source-2.6.10 and recompiled it. > AtyFB on my SB100 works now (sort of), but the console misses the first > column on the left and some random pixels are corrupted. Under XFree86 > I've got the same corruption of randome areas of the screen (I'll try to > get some screenshot if this is of help). > > This is the relevant output of kernel (really I still don't know how to > interpret it... :-)): The mach64 chip on the SB100 has some very odd PLL clock inputs compared the what is shipped on PCI and AGP cards sold for PCs. Reporting these details here isn't really going to help much, as the folks active with the kernel ATI driver don't read this mailing list. Could you please, therefore, report your stuff to [EMAIL PROTECTED] who seems to be the most active person working on this driver lately? Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: AtyFB in 2.6.10, still not perfect
Il giorno lun, 14-03-2005 alle 15:04 -0800, David S. Miller ha scritto: > The mach64 chip on the SB100 has some very odd PLL clock inputs compared > the what is shipped on PCI and AGP cards sold for PCs. > > Reporting these details here isn't really going to help much, as the > folks active with the kernel ATI driver don't read this mailing list. > Could you please, therefore, report your stuff to [EMAIL PROTECTED] > who seems to be the most active person working on this driver lately? Thanks for the direction, David. I just didn't know who to contact, I'm forwarding the mail to hi now. Regards, -- Luigi Gangitano -- <[EMAIL PROTECTED]> -- <[EMAIL PROTECTED]> GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972 C24A F19B A618 924C 0C26 signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Re: Bits (Nybbles?) from the Vancouver release team meeting
> > We project that applying these rules for etch will reduce the set of > > candidate architectures from 11 to approximately 4 (i386, powerpc, ia64 > > and amd64 -- which will be added after sarge's release when mirror space > > no sparc here. > > After speaking to Andreas Barth, asking, why sparc might become SCC, he > pointed my to the last release update where it says: > > | It's for this reason that all architectures are > | required to be synced to the same kernel version for sarge, but even so, > | more per-architecture kernel help is needed, particularly for the sparc > | and the arm port. > > So we seem to have a lack of sparc kernel hackers/developers. > I myself are using Debian on sparc very much, but do not have the > knowledge with sparc kernels to help here. I know a little and would be willing to help if it meant that sparc would stay a 'first class citizen'. I don't have much time but I suspect that a little time given to helping Debian/SPARC would be better than having to port everything I run to a different distro / UNIX just to have consistancy. > The only thing i could do here is testing, testing, testing... > > > - 5 developers who will use or work on the port must send in > > signed requests for its addition > > > > - the port must demonstrate that they have at least 50 users > > That should be possible somehow. Guess so. Is there anyone 'in charge' of the Debian/sparc port or anyone co-ordinating the fight to keep Debian/sparc a live port? Cheers, - Martin -- Martin [EMAIL PROTECTED] "Seasons change, things come to pass" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SunBlade D-I problems (was: Bits (Nybbles?) from the Vancouver release team meeting)
Hi David, On Monday 14 March 2005 23:24, David S. Miller wrote: > > We seem to have some serious problems with d-i on newer sun systems > > (such as sun blades). Keyboard doesn't work, CD may not work. This > > may or may not be a kernel problem. > > > > Just one thing I happen to know of. > > Which exact blade models? My SB1500 is my main workstaion and besides > that (fixed) clock probing issue, the machine works flawlessly. There > are minor ATI Radeon xfree86 driver issues, which I'll submit fixes > for, but simply using "fbdev" as the driver works perfectly fine and > works around those problems. See installation-report #298927 in BTS [1]. Also this [2] thread on d-boot. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298927 [2] http://lists.debian.org/debian-boot/2005/03/msg00249.html There is also #299074 [3], but that is probably unrelated. [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299074 Cheers, FJP pgp35TgEcDoLL.pgp Description: PGP signature
AtyFB in 2.6.10, still not perfect
Hi all, I've just upgraded to the latest kernel-source-2.6.10 and recompiled it. AtyFB on my SB100 works now (sort of), but the console misses the first column on the left and some random pixels are corrupted. Under XFree86 I've got the same corruption of randome areas of the screen (I'll try to get some screenshot if this is of help). This is the relevant output of kernel (really I still don't know how to interpret it... :-)): atyfb: 3D RAGE XL (Mach64 GR, PCI-33MHz) [0x4752 rev 0x27] atyfb: 8M SDRAM (1:1), 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK atyfb: setting up CRTC atyfb: set primary CRT to 1152x900 NN composite P atyfb: CRTC_H_TOTAL_DISP: 8f00be atyfb: CRTC_H_SYNC_STRT_WID: 300296 atyfb: CRTC_V_TOTAL_DISP: 38303a8 atyfb: CRTC_V_SYNC_STRT_WID: 240385 atyfb: CRTC_OFF_PITCH: 2400 atyfb: CRTC_VLINE_CRNT_VLINE: 0 atyfb: CRTC_GEN_CNTL: b000210 atyfb: atyfb_set_par atyfb: Set Visible Mode to 1152x900-8 atyfb: Virtual resolution 1152x7246, pixclock_in_ps 10644 (calculated 10644) atyfb: Dot clock: 93 MHz atyfb: Horizontal sync: 61 kHz atyfb: Vertical refresh:65 Hz atyfb: x style: 93.10108 1152 1210 1338 1528 900 902 906 937 atyfb: fb style: 10644 190 1152 58 128 31 900 2 4 debug atyfb: Mach64 non-shadow register values: debug atyfb: 0x2000: 008F00BE 00300296 038303A8 00240385 debug atyfb: 0x2010: 0388 2400 0801 0B002210 debug atyfb: 0x2020: 003A0556 01200522 debug atyfb: 0x2030: 00110202 C001 debug atyfb: 0x2040: debug atyfb: 0x2050: debug atyfb: 0x2060: 36BB3121 24FBA121 debug atyfb: 0x2070: 01003300 0005 debug atyfb: 0x2080: debug atyfb: 0x2090: 00803000 0100 debug atyfb: 0x20A0: 7B23A040 0101 007F8091 E5000C81 debug atyfb: 0x20B0: 10151A3B 0001 0001 debug atyfb: 0x20C0: 00FF 86010182 debug atyfb: 0x20D0: 0100 0008 00C2 debug atyfb: 0x20E0: 27004752 00400014 debug atyfb: 0x20F0: B14D 037FFCF8 debug atyfb: Mach64 PLL register values: debug atyfb: 0x00: ADD541E4 8A0301CF 8E9E6501 801B debug atyfb: 0x10: 06CF4000 10B6AC10 408024FD 0002 debug atyfb: 0x20: 06AC06AC 1424FD00 00255500 debug atyfb: 0x30: Console: switching to colour frame buffer device 144x56 atyfb: fb0: ATY Mach64 frame buffer device on PCI Regards, -- Luigi Gangitano -- <[EMAIL PROTECTED]> -- <[EMAIL PROTECTED]> GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972 C24A F19B A618 924C 0C26 signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, 14 Mar 2005 16:59:49 -0500 Joey Hess <[EMAIL PROTECTED]> wrote: > Mark Brown wrote: > > Me too, probably. I'd managed to completely miss the call for help in > > the last status updates (looking at the announcement I must've started > > skimming well before the call for help in the kernel section). > > > > Outside of the kernel what areas need attention for SPARC? > > We seem to have some serious problems with d-i on newer sun systems > (such as sun blades). Keyboard doesn't work, CD may not work. This may > or may not be a kernel problem. > > Just one thing I happen to know of. Which exact blade models? My SB1500 is my main workstaion and besides that (fixed) clock probing issue, the machine works flawlessly. There are minor ATI Radeon xfree86 driver issues, which I'll submit fixes for, but simply using "fbdev" as the driver works perfectly fine and works around those problems. Also, my CDROM and USB keyboard worked fine. I have a SB100 and a SB1000 here as well for testing and fixing such problems. The only thing really missing from my arsenal are SB150 and SB2500. I'd accept donations of either for sparc64 support purposes (hint hint) :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Monday 14 March 2005 22:59, Joey Hess wrote:
> We seem to have some serious problems with d-i on newer sun systems
> (such as sun blades). Keyboard doesn't work, CD may not work.
There is progress on the keyboard issue for SunBlade, though solving it
completely take some doing as there are several issues interacting.
The best option currently seems to be installing at medium priority and
choosing "no keyboard" as the default kernel keymap works fine.
If there are ppl with a non-US keyboard, they should choose an USB
keyboard and pray their layout installs without errors.
FYI the following mail I received privately from Vincent McIntyre.
Cheers,
-- Forwarded Message --
Subject: Re: confirm: sb100 keyboard partial success
Date: Sunday 13 March 2005 22:32
From: [EMAIL PROTECTED]
To: Frans Pop <[EMAIL PROTECTED]>
> Please try selecting here and then the menu item for keyboard
> selection; you should get a menu showing different keyboard types.
this is what I get for the keyboard selection menu.
Select A Keyboard Layout
Sun keyboard
PC-style (AT or PS-2 connector) keyboard
USB keyboard
No keyboard to configure
[go back]
Sun Keyboard is highlighted.
> What happens if you select a usb-mac keyboard (instead of a SUN-type
> keyboard) and one of the keymaps shown there?
Choosing USB keyboard (there was no "usb-mac" option)
takes me to the "Select a keyboard layout" menu.
> Please try both US keymap, UK keymap _and_ one of the others (e.g.
> German).
US (American English)
I get "installation step failed". The failing step was "Select a
keyboard layout".
UK (British English)
I get into the "detect cdrom" stage, which fails as usual.
The keyboard is working ok.
DE ("German")
I get into the "detect cdrom" stage, which fails as usual.
The keyboard is working ok.
At this stage I tried to select "open a shell"
This worked, in contrast to the previous time.
The keymap is not quite right: "/" is mapped to "-", "y" & "z"
are swapped, "&" maps to "/", etc.
This might be expected, given the "wrong" choice I made.
> What happens if you select an AT (PS/2) keymap?
Without rebooting, ie trying to switch from USB to AT/PS2, I get an
"installation step failed" message.
> What happens if you select "No keyboard"?
Again w/o rebooting, from the main menu I go into "select kb layout"
and choose "no keyboard to configure". I am taken back to the main menu.
The keyboard seems to be working still.
If I reboot, and do the "go back" step as at the top of this mail, then
choose "No keyboard to configure", I get taken directly to the "detect
and mount cdrom" step.
The keyboard works ok. Starting a shell, all the keys are mapped ok.
Poking in /var/log/syslog, I see some interesting things.
I've transcribed (and now my hands hurt) what happens when I choose
'no kbd' as described just above.
debconf: setting debconf/language to en
debconf: setting debconf/language to US_en:GB_en:en
languagechooser: info: asking for language specific packages to be
installed.
languagechooser: info: debian-installer/locale='en'
languagechooser: info: debian-installer/fallbacklocale='[EMAIL PROTECTED]'
languagechooser: info: languagechooser/locale='en'
languagechooser: info: debian-installer/language='en_US:en_GB:en'
languagechooser: info: debian-installer/country='US'
languagechooser: info:
debian-installer/consoledisplay='kbd=lat0-sun16(iso15)'
snip
main-menu(389): DEBUG: Menu item 'countrychooser' selected
main-menu(389): DEBUG: configure countrychooser status: 2
main-menu(389): DEBUG: configure iso-3166-udeb status: 2
countrychooser: info: LANGUAGECODE_LANGUAGECHOOSER = 'en'
countrychooser: info: COUNTRYCODE_LANGUAGECHOOSER = 'US'
countrychooser: info: LOCALE_LANGUAGECHOOSER = 'en'
countrychooser: info: FALLBACKLOCALE = '[EMAIL PROTECTED]'
countrychooser: info: set debian-installer/locale = 'en_AU'
countrychooser: info: set debian-installer/language =
'en_AU:en_US:en_GB:en'
main-menu(389): DEBUG: Menu item 'kbd-chooser' selected
main-menu(389): DEBUG: configure kbd-chooser, status: 2
main-menu(389): DEBUG: configure libc6, status: 0
main-menu(389): DEBUG: configure libdebconfclient0, status: 0
main-menu(389): INFO: falling back to the package description for
libdebconfclient0-udeb
main-menu(389): INFO: falling back to the package description for
libdebconfclient0-udeb
main-menu(389): DEBUG: configure libdebconfclient0-udeb, status: 2
main-menu(389): DEBUG: configure libc6, status: 0
main-menu(389): DEBUG: configure libdebian-installer4, status: 0
main-menu(389): DEBUG: virtual package libdebian-installer4
main-menu(389): DEBUG: configure console-keymaps, status: 0
main-menu(389): DEBUG: virtual package console-keymaps
main-menu(389): INFO: falling back to the package description for
console-keymaps-usb
main-menu(389): INFO: falling back to the package description for
console-keymaps-sun
main-menu(389): INFO: fallin
Re: Bits (Nybbles?) from the Vancouver release team meeting
Mark Brown wrote: > Me too, probably. I'd managed to completely miss the call for help in > the last status updates (looking at the announcement I must've started > skimming well before the call for help in the kernel section). > > Outside of the kernel what areas need attention for SPARC? We seem to have some serious problems with d-i on newer sun systems (such as sun blades). Keyboard doesn't work, CD may not work. This may or may not be a kernel problem. Just one thing I happen to know of. -- see shy jo, not a sparc guy signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
Jurij Smakov a écrit : A few DDs who are most probably interested in keeping the sparc port up and running are Joshua Kwan, Andres Solomon, Blars Blarson and Ben Collins. I don't know what I can do to help, but I am also interested in keeping the sparc port up (I own a sparc machine and I am a DD). One third of my packages uploads are sparc ones, the two others beeing hppa and mips. I don't do any i386 uploads since the first rumors of the SCC plan. Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 11:24:27AM -0500, Jurij Smakov wrote: > A few DDs who are most probably interested in keeping the sparc port up > and running are Joshua Kwan, Andres Solomon, Blars Blarson and Ben > Collins. Me too, probably. I'd managed to completely miss the call for help in the last status updates (looking at the announcement I must've started skimming well before the call for help in the kernel section). Outside of the kernel what areas need attention for SPARC? -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, 14 Mar 2005, Martin Zobel-Helas wrote: that won't work what we need here is some guys who a willing to do active kernel work on debian sparc. Well, I have been recently accepted as a member of the debian-kernel team, specifically for the purpose of tracking and fixing the sparc-related issues. The kernel situation on sparc is really not that bad, apart from a few serious bugs on newer hardware, to which I don't have access to. A few DDs who are most probably interested in keeping the sparc port up and running are Joshua Kwan, Andres Solomon, Blars Blarson and Ben Collins. Greetings Martin Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Hi Patrick, On Monday, 14 Mar 2005, you wrote: > I'll make a standard pdf letter folks can print and sign and send if > they'd like. > > They cannot kill the sparc line off, Debian is my favorite distro for > Sparc, we've got to do something about this! that won't work what we need here is some guys who a willing to do active kernel work on debian sparc. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, 14 Mar 2005 14:23:17 +0100, Martin Zobel-Helas <[EMAIL PROTECTED]> wrote: > Hi List, > > On Sunday, 13 Mar 2005, Steve Langasek wrote: > [...] > > > > Therefore, we're planning on not releasing most of the minor architectures > > starting with etch. They will be released with sarge, with all that > > implies (including security support until sarge is archived), but they > > would no longer be included in testing. > [...] > > We project that applying these rules for etch will reduce the set of > > candidate architectures from 11 to approximately 4 (i386, powerpc, ia64 > > and amd64 -- which will be added after sarge's release when mirror space > > no sparc here. > > After speaking to Andreas Barth, asking, why sparc might become SCC, he > pointed my to the last release update where it says: > > | It's for this reason that all architectures are > | required to be synced to the same kernel version for sarge, but even so, > | more per-architecture kernel help is needed, particularly for the sparc > | and the arm port. > > So we seem to have a lack of sparc kernel hackers/developers. > I myself are using Debian on sparc very much, but do not have the > knowledge with sparc kernels to help here. > > The only thing i could do here is testing, testing, testing... > > > - 5 developers who will use or work on the port must send in > > signed requests for its addition > > > > - the port must demonstrate that they have at least 50 users > > That should be possible somehow. I'll make a standard pdf letter folks can print and sign and send if they'd like. They cannot kill the sparc line off, Debian is my favorite distro for Sparc, we've got to do something about this! -- Get your daily dose of tech at http://TopLevel.Blogspot.com -- "Life should NOT be a journey to the grave with the intention of arriving safely in an attractive and well preserved body, but rather to skid in sideways, cigar in one hand, beer in the other, body thoroughly used up, totally worn out and screaming "WOO HOO what a ride!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Hi List, On Sunday, 13 Mar 2005, Steve Langasek wrote: [...] > > Therefore, we're planning on not releasing most of the minor architectures > starting with etch. They will be released with sarge, with all that > implies (including security support until sarge is archived), but they > would no longer be included in testing. [...] > We project that applying these rules for etch will reduce the set of > candidate architectures from 11 to approximately 4 (i386, powerpc, ia64 > and amd64 -- which will be added after sarge's release when mirror space no sparc here. After speaking to Andreas Barth, asking, why sparc might become SCC, he pointed my to the last release update where it says: | It's for this reason that all architectures are | required to be synced to the same kernel version for sarge, but even so, | more per-architecture kernel help is needed, particularly for the sparc | and the arm port. So we seem to have a lack of sparc kernel hackers/developers. I myself are using Debian on sparc very much, but do not have the knowledge with sparc kernels to help here. The only thing i could do here is testing, testing, testing... > - 5 developers who will use or work on the port must send in > signed requests for its addition > > - the port must demonstrate that they have at least 50 users That should be possible somehow. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
