Re: WG: Re: Bits (Nybbles?) from the Vancouver release team meeting
Linux qux 2.6.11.5 #1 Wed Mar 23 13:23:49 PST 2005 sparc64 GNU/Linux
--- "David S. Miller" <[EMAIL PROTECTED]> wrote:
> On Tue, 26 Apr 2005 23:01:57 -0700 (PDT)
> <[EMAIL PROTECTED]> wrote:
>
> > The dmesg outputs motivating my original (misinterpreted and/or
> poorly
> > phrased) IDE controller rant:
> > hdc: dma_timer_expiry: dma status == 0x60
> > hdc: DMA timeout retry
> > hdc: timeout waiting for DMA
> > hdc: status error: status=0x58 { DriveReady SeekComplete
> DataRequest }
> > hdc: drive not ready for command
>
> What kernel version gives you this?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WG: Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, 26 Apr 2005 23:01:57 -0700 (PDT)
<[EMAIL PROTECTED]> wrote:
> The dmesg outputs motivating my original (misinterpreted and/or poorly
> phrased) IDE controller rant:
> hdc: dma_timer_expiry: dma status == 0x60
> hdc: DMA timeout retry
> hdc: timeout waiting for DMA
> hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> hdc: drive not ready for command
What kernel version gives you this?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WG: Re: Bits (Nybbles?) from the Vancouver release team meeting
Thanks for working with me on this. Your help is appreciated. I've
combined the benchmarks, some system info, and some other hard disk /
controller / driver issues together below. I attempted to label the
sub-sections clearly to make this readable.
When I saw your first numbers, I too was surprised with the low scores.
However (luckily) I get better numbers. I did some experimentation with
the disk flags as you (very wisely) advised on one of the disks for
comparison purposes and it majorly increased the score.
Some things:
I used DMA66 thin ribbon / ground cables.
One of my drives is not "stock".
The dmesg outputs motivating my original (misinterpreted and/or poorly
phrased) IDE controller rant:
hdc: dma_timer_expiry: dma status == 0x60
hdc: DMA timeout retry
hdc: timeout waiting for DMA
hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: drive not ready for command
hdc: status timeout: status=0xd0 { Busy }
Do you suppose I ought to be blaming Seagate or Sun's firmware for the
drive instead?; I just assumed it must be CMD's fault because it
usually is. Given you are the SPARC expert of note in the Debian arena,
your opinion on this issue is greatly valued. I am concerned this might
at some point frobnicate my boot drive from the snafu state to the
fubar state, so to speak. :-)
dmesg config strings:
hda: WDC WD400EB-00CPF0, ATA DISK drive
hdc: ST39140A, ATA DISK drive
benchmark log:
[EMAIL PROTECTED]:~# /sbin/hdparm -c3 -m16 -d1 -X34 /dev/hda
/dev/hda:
setting 32-bit IO_support flag to 3
setting multcount to 16
setting using_dma to 1 (on)
setting xfermode to 34 (multiword DMA mode2)
multcount= 16 (on)
IO_support = 3 (32-bit w/sync)
using_dma= 1 (on)
[EMAIL PROTECTED]:~#
[EMAIL PROTECTED]:~# /sbin/hdparm -t /dev/hda
/dev/hda:
Timing O_DIRECT disk reads: 46 MB in 3.10 seconds = 14.82 MB/sec
[EMAIL PROTECTED]:~#
[EMAIL PROTECTED]:~# /sbin/hdparm -t /dev/hdc
/dev/hdc:
Timing O_DIRECT disk reads: 10 MB in 3.03 seconds = 3.30 MB/sec
[EMAIL PROTECTED]:~# /sbin/hdparm -c3 -m16 -d1 -X34 /dev/hdc
/dev/hdc:
setting 32-bit IO_support flag to 3
setting multcount to 16
setting using_dma to 1 (on)
setting xfermode to 34 (multiword DMA mode2)
multcount= 16 (on)
IO_support = 3 (32-bit w/sync)
using_dma= 1 (on)
[EMAIL PROTECTED]:~# /sbin/hdparm -t /dev/hdc
/dev/hdc:
Timing O_DIRECT disk reads: 42 MB in 3.03 seconds = 13.87 MB/sec
[EMAIL PROTECTED]:~#
--- "David S. Miller" <[EMAIL PROTECTED]> wrote:
> On Tue, 26 Apr 2005 18:35:37 -0700 (PDT)
> <[EMAIL PROTECTED]> wrote:
>
> > What kind of benchmark did you run?
> > It would be sort of silly if I didn't do a similar test.
>
> /sbin/hdparm -t /dev/hda
>
> which does an uncached O_DIRECT 20MB read from the IDE
> disk, it's the real disk bandwidth not a cached number.
>
> Also, try "/sbin/hdparm -c3 -m16 -d1 -X34 /dev/hda" if
> the performance stinks even worse than the 6.6MB I'm
> getting. DMA tends to not get enabled by default unless
> the disk is in the IDE layer white list, the Seagate's
> that came standard in Ultra5 and Ultra10 systems just
> so happen to be in that white list.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WG: Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, 26 Apr 2005 18:35:37 -0700 (PDT) <[EMAIL PROTECTED]> wrote: > What kind of benchmark did you run? > It would be sort of silly if I didn't do a similar test. /sbin/hdparm -t /dev/hda which does an uncached O_DIRECT 20MB read from the IDE disk, it's the real disk bandwidth not a cached number. Also, try "/sbin/hdparm -c3 -m16 -d1 -X34 /dev/hda" if the performance stinks even worse than the 6.6MB I'm getting. DMA tends to not get enabled by default unless the disk is in the IDE layer white list, the Seagate's that came standard in Ultra5 and Ultra10 systems just so happen to be in that white list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WG: Re: Bits (Nybbles?) from the Vancouver release team meeting
What kind of benchmark did you run? It would be sort of silly if I didn't do a similar test. I will see if I can get Solaris benchmarks for you as well, but it will take a while. --- "David S. Miller" <[EMAIL PROTECTED]> wrote: > > I tried everything I could and I can't get more then 6.6MB/sec > out of the IDE disks on my Ultra10's. > > If anyone can quote better numbers on Solaris, or *BSD, or > whatever, let me hear about it. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WG: Re: Bits (Nybbles?) from the Vancouver release team meeting
I tried everything I could and I can't get more then 6.6MB/sec out of the IDE disks on my Ultra10's. If anyone can quote better numbers on Solaris, or *BSD, or whatever, let me hear about it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WG: Re: Bits (Nybbles?) from the Vancouver release team meeting
--- "David S. Miller" <[EMAIL PROTECTED]> wrote: > On Fri, 22 Apr 2005 21:41:13 -0700 (PDT) > <[EMAIL PROTECTED]> wrote: > > > Oh shit, don't get me started on that IDE controller! > > I wish people would code as much as they complain. > > I'll see what I can do about making the cmd646 driver > use better PIO and DMA timings like the OpenBSD and > NetBSD one aparently does on Ultra5/Ultra10 et al.. > > Little girls, quit whining... I'm sorry if I came across as ungrateful. I don't blame you or think of you as unhelpful at all. In actuality, I blame Sun and CMD Technology for using such a dreadful chip. I was just trying to share some humor and a feeling of compassion / sympathy with another user who had the same problem that I did. I failed to make these things clear in my e-mail. Sorry. Also, I would like to help with the SPARC kernel. I am experienced with C but lacking in expertise with hardware and drivers. Please let me know if there is something I could do. It's not that I don't want to help, it's that I'm too damn incompetent. :-) Have a good day! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WG: Re: Bits (Nybbles?) from the Vancouver release team meeting
On Fri, 22 Apr 2005 21:41:13 -0700 (PDT) <[EMAIL PROTECTED]> wrote: > Oh shit, don't get me started on that IDE controller! I wish people would code as much as they complain. I'll see what I can do about making the cmd646 driver use better PIO and DMA timings like the OpenBSD and NetBSD one aparently does on Ultra5/Ultra10 et al.. Little girls, quit whining... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WG: Re: Bits (Nybbles?) from the Vancouver release team meeting
--- Francois Lucas <[EMAIL PROTECTED]> wrote: > On 3/17/05, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: > > Ok, then why did it say my UltraSPARC II processor was not > supported > > when I tried to install Solaris 10 on the system once before? > > Don't know ! But I can say that it works perfectly well on my USIIi > 440Mhz Ultra10 (modulo the sucking IDE controller) Oh shit, don't get me started on that IDE controller! I'm already neck deep in the GFDL freeness debate. :-) I get weird kernel messages from it all the time, but what can I do? I'm 2000 miles away trying to keep my head above water on a new job. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WG: Re: Bits (Nybbles?) from the Vancouver release team meeting
On 3/17/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Ok, then why did it say my UltraSPARC II processor was not supported > when I tried to install Solaris 10 on the system once before? Don't know ! But I can say that it works perfectly well on my USIIi 440Mhz Ultra10 (modulo the sucking IDE controller) -- F.
Re: WG: Re: Bits (Nybbles?) from the Vancouver release team meeting
Ok, then why did it say my UltraSPARC II processor was not supported when I tried to install Solaris 10 on the system once before? --- [EMAIL PROTECTED] wrote: > > 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. > > > > At least that statement is not true. According to the release notes > (http://docs.sun.com/app/docs/doc/817-0552/6mgbi4fh8?a=view) > and my personal experience, Solaris 10 runs on anything sun4u with > CPU speed > 200 MHz. > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
WG: 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. > At least that statement is not true. According to the release notes (http://docs.sun.com/app/docs/doc/817-0552/6mgbi4fh8?a=view) and my personal experience, Solaris 10 runs on anything sun4u with CPU speed > 200 MHz. -- 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 (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: 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
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]
