* Re: small fix for nforce ide chipset driver in 2.5.54
From: Alan Cox @ 2003-01-09 17:49 UTC (permalink / raw)
To: James Curbo; +Cc: Andre Hedrick, Linux Kernel Mailing List
In-Reply-To: <20030109065642.GA6251@carthage>
On Thu, 2003-01-09 at 06:56, James Curbo wrote:
> Well, I thought this deal was over but apparently not. My 2.5.54 kernel
> is still working fine, but when I compiled 2.4.20-ac2, it didn't pick up
> my Nforce2 IDE. On a whim I checked include/linux/pci_ids.h and it has a
> different PCI ID for PCI_DEVICE_ID_NVIDIA_NFORCE_IDE, namely 0x01bc.
> (lspci -v reports 0x0065 here). Perhaps 0x01bc is the nforce1 ide
> chipset and 0x0065 is the nforce2 ide chipset?
2.4.21pre3-ac2 should support the Nforce and Nforce2. Its not the final driver
for 2.4 or 2.5 (there is a much nicer merged AMD/Nvidia one) but it will wait
until after 2.4.21 before I merge it.
^ permalink raw reply
* Re: Some ALSA documents on line
From: Patrick Shirkey @ 2003-01-09 16:54 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5hel7m8eqa.wl@alsa2.suse.de>
Takashi Iwai wrote:
> Hi Patrick,
> - ALSA Driver API Reference
>
> http://www.alsa-project.org/~iwai/alsa-driver-api/index.html
> http://www.alsa-project.org/~iwai/alsa-driver-api.pdf
> http://www.alsa-project.org/~iwai/alsa-driver-api.sgml
>
Is this generated daily in cvs or are you doing it manually?
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================
Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.
Goldie, 8 Nov, 2002
The Scotsman
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: 405LP sleep, no PTEs (was: get_pteptr prototype)
From: Hollis Blanchard @ 2003-01-09 16:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: paulus, devel list
In-Reply-To: <1042107732.567.2.camel@zion.wanadoo.fr>
[-- Attachment #1: Type: text/plain, Size: 574 bytes --]
On Thu, 2003-01-09 at 04:22, Benjamin Herrenschmidt wrote:
> On Thu, 2003-01-09 at 01:11, Hollis Blanchard wrote:
> >
> > Alternatively I can add 405LP to the XMON/KGDB/BDI2000 list of ifdefs
> > that map the whole kernel writable, which would be overkill but avoid
> > adding PTE manipulations.
>
> A simpler solution would be to just disable MSR:DR while filling the
> wakeup infos.
You're right. The update is attached and at
http://penguinppc.org/~hollis/405LP-sleep.diff . The PTE manipulations
have been removed.
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
[-- Attachment #2: 405LP-sleep.diff.gz --]
[-- Type: application/x-gzip, Size: 13438 bytes --]
^ permalink raw reply
* Getting dosemu running again
From: Rich Shepard @ 2003-01-09 16:52 UTC (permalink / raw)
To: linux-msdos
I need some help on this as I've failed to solve it on my own. For several
years I had three hard drives on my workstation and PC-DOS/7 was installed
in the mbr of /dev/hdb. Last September, I upgraded both the linux
distribution (from RH 6.2 to 7.3) and I replaced both /dev/hda and /dev/hdb
with a new, much larger drive that is designated /dev/hda. (The former
/dev/hdc is now /dev/hdb.)
All of pc-dos7 is in a vfat partition (/dos7) that is mounted on
/dev/hda10 (except when I want to run dosemu). The root of that filesystem
/contains all the system files:
4dos.com* dev/ ibmbio.com* mouse/ temp/
4dosswap.000* dos/ ibmdos.com* notes/ ttfonts/
autoexec.bat* exitemu.com* info/ recycled/ utils/
config.sys* f/ library/ ted.com*
However, when I try to invoke dosemu now, this is what I get (rather than
the c:/> prompt):
Linux DOS emulator 1.0.0.0 $Date: 2000/03/05 $
Last configured at Sun Mar 5 21:50:56 MET 2000 on linux
This is work in progress.
Please test against a recent version before reporting bugs and problems.
Bugs, Patches & New Code to linux-msdos@vger.rutgers.edu
DPMI-Server Version 0.9 installed
This is not a bootable disk. Please insert a bootable floppy and
press any key to try again ...
I'm not sure how to modify /etc/dosemu.conf to reflect the presence of
ibmbio.com and ibmdos.com (as well as the command interpreter, 4dos.com) on
/dos7. I've tried figuring this out from the docs and by looking at the conf
file. But, I'm stymied.
In /etc/doesmu.conf I have this:
# $_hdimage = "hdimage.first /dev/hda10"
$_hdimage = "/dev/hda10"
But, dosemu won't load when /dos7 is mounted at that point.
I'd greatly appreciate being educated in what I need to do to resolve my
confusion and get dosemu running once again.
Thanks,
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
http://www.appl-ecosys.com/
^ permalink raw reply
* Re: APIC with SIS
From: Stephan von Krawczynski @ 2003-01-09 16:59 UTC (permalink / raw)
To: Justin Cormack; +Cc: linux-kernel
In-Reply-To: <1042130749.25527.5.camel@lotte>
On 09 Jan 2003 16:45:44 +0000
Justin Cormack <justin@street-vision.com> wrote:
> > > Current ACPI is on sourceforge. The SIS APIC workaround bits haven't yet
> > > been backported to 2.4, so you either do the backport or wait 8)
> >
> > Ok, so I took ACPI from sf and voila: it works now! I took the patch for
> > 2.4.20 and it does fine. Are there chances to include this in the
> > mainstream? Without my SIS-based motherboards do not work at all with
> > shared interrupts (which you actually cannot prevent due to lacking bios
> > support for pci-irq mapping).
> >
> > BTW: I tried 2.4.21-pre[1-3] and none did work, of course.
>
> You may be able to disable the APIC in the BIOS. One of my new Sis
> boards gave this option and it is an ok workaround for now at least.
Unfortunately it is not. Shared interrupts do _not_ work with APIC disabled.
They _only_ work with APIC enabled in BIOS _and_ APIC support patch from sf.
I tested every other combination and none did work.
--
Regards,
Stephan
^ permalink raw reply
* Re: kswapd CPU usage and heavy disk IO
From: Anders Widman @ 2003-01-09 16:50 UTC (permalink / raw)
To: Dieter Nützel
Cc: Brian Tinsley, Russell Coker, ReiserFS, Rik van Riel,
Andrea Arcangeli, Linux Kernel List
In-Reply-To: <200301091742.51101.Dieter.Nuetzel@hamburg.de>
> Are you sure it is a ReiserFS and not a kernel thing?
I would think it is probably not. I have seen this also when running
things like "badblocks /dev/hdb" and the kswapd eats up all CPU
recourses. Then again I am always using ReiserFS so I do not know if
the ReiserFS is the cause or not.. But judging from badblocks is not
FS dependantI think there is no wrong with ReiserFS =)
//Anders
^ permalink raw reply
* Re: kswapd CPU usage and heavy disk IO
From: Brian Tinsley @ 2003-01-09 16:48 UTC (permalink / raw)
To: Dieter Nützel
Cc: Russell Coker, ReiserFS, Rik van Riel, Andrea Arcangeli,
Linux Kernel List
In-Reply-To: <200301091742.51101.Dieter.Nuetzel@hamburg.de>
Dieter Nützel wrote:
>I think you should have cc'ed Andrea Arcangeli <andrea@suse.de>, LKM and try
>2.4.20-aa1.
>
I've got the -aa1 patch, but I have not been able to build the Linux
Virtual Server code with it yet. I absolutely depend on this and have a
request for assistance posted to that mailing list.
>Are you sure it is a ReiserFS and not a kernel thing?
>
I don't believe it's a reiserfs issue. That's just where this thread
started. IMHO, it's a kernel issue.
>
>
--
-[========================]-
-[ Brian Tinsley ]-
-[ Chief Systems Engineer ]-
-[ Emageon ]-
-[========================]-
^ permalink raw reply
* Re: MB without keyboard controller / USB-only keyboard ?
From: Alan Cox @ 2003-01-09 17:42 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: Linux Kernel Mailing List
In-Reply-To: <20030109114247.211f7072.skraw@ithnet.com>
On Thu, 2003-01-09 at 10:42, Stephan von Krawczynski wrote:
> Hello all,
>
> how do I work with a mb that contains no keyboard controller, but has only USB
> for keyboard and mouse?
> While booting the kernel I get:
>
> pc_keyb: controller jammed (0xFF)
Does your BIOS do keyboard emulation ?
^ permalink raw reply
* [parisc-linux] ibm-disk on a hp 735/125
From: Joerg Krebs @ 2003-01-09 16:44 UTC (permalink / raw)
To: parisc-linux
Hello all,
im running a hp 735/125 with a st31200wd 1GB harddisk, connected to the
fast-wide scsi-connector, which run's quit nice.
But now I want to replace the disk with a larger 4,3GB ibm dcas-34330
disk, but I can't get it be detected by the system, I think i used the
same jumper settings as on the old seagate drive.
at the search for potential boot devices nothing appears.
So perhaps someones uses the same harddisk and can tell me the right
jumper-settings, the disk itself works fine with a normal PC with a
scsi-wide controller.
Thanks for your help
J. Krebs
^ permalink raw reply
* Re: What's in a name?
From: venom @ 2003-01-09 16:51 UTC (permalink / raw)
To: Richard B. Johnson; +Cc: vlad, 'John Alvord', linux-kernel, rms
In-Reply-To: <Pine.LNX.3.95.1030109110746.10873A-100000@chaos.analogic.com>
Yes, for binaries most of the time we even did not need to use the
/usr/lib/libbsd.a compatibility library
and the /usr/include/bsd/*.h compatibility includes
(just ash was needing that) coming with libc4 and libc5 distribution for
compatibility pursues.
Then also the boot system was BSD like, and now we see this prosecuted and
evolved in Slackware.
But please, let's stop this thread.
We talked about GPLed modules and binary only modules,
and none even considered implication brought
by the new module interface with run queue, that is an important
point in this discussion.
We talked just about names, names, names, and again names.
I do not expect in every thread on lkml to see some good contribution
(not just code, but concept, discussions, and so on),
but this specific one is just like
"the wall I build with my belief is higher than your".
And the few smart mails ususally got ignored.
There is no interess in this for me.
Luigi
On Thu, 9 Jan 2003, Richard B. Johnson wrote:
> Most all of the early distributions
> used programs ported from BSD. The Linux-BSD emulation was so good,
> thanks to Linus and others, that most programs needed to only be
> recompiled.
>
> That, ladies and gentlemen, is the true history of the "Linux Operating
> System" with all of the components that RMS insists are his, actually
> coming from the University of California, Berkeley.
>
^ permalink raw reply
* Re: kswapd CPU usage and heavy disk IO
From: Dieter Nützel @ 2003-01-09 16:42 UTC (permalink / raw)
To: Brian Tinsley, Russell Coker
Cc: ReiserFS, Rik van Riel, Andrea Arcangeli, Linux Kernel List
In-Reply-To: <3E1D9D10.40700@emageon.com>
Am Donnerstag, 9. Januar 2003 17:02 schrieb Brian Tinsley:
> I've been seeing the exact same thing on the same type of system in the
> same situations. This has been causing all kinds of problems on our
> clusters: the system live-locks for a minute or two, causes cluster
> heartbeats to not be received, and falsely fails over when the system
> recovers from the live-lock. The only thing I can find after the
> live-lock is that the runtime for kswapd is abnormally high.
>
> We started running sar (60 second collection interval) and were able to
> capture some stats during this live-lock period. I've snipped some I
> believe may be of interest. Note the missing stats between 03:59:43 and
> 04:02:03
>
> Oh BTW, this is on a stock 2.4.20 kernel (dual P3, 4GB), but I have seen
> the same behavior on 2.4.19 and 2.4.17.
I think you should have cc'ed Andrea Arcangeli <andrea@suse.de>, LKM and try
2.4.20-aa1.
Are you sure it is a ReiserFS and not a kernel thing?
Regards,
Dieter
> 1. sar -f sa09 -r
>
> 03:53:43 AM kbmemfree kbmemused %memused kbmemshrd kbbuffers kbcached
> kbswpfree kbswpused %swpused
> 03:54:43 AM 411888 3888264 90.42 0 629520
> 2666968 209713
> 6 0 0.00
> 03:55:43 AM 396684 3903468 90.78 0 658656
> 2667160 209713
> 6 0 0.00
> 03:56:43 AM 331360 3968792 92.29 0 675008
> 2733476 209713
> 6 0 0.00
> 03:57:43 AM 231588 4068564 94.61 0 683680
> 2832816 209713
> 6 0 0.00
> 03:58:43 AM 209740 4090412 95.12 0 702148
> 2854332 209713
> 6 0 0.00
> 03:59:43 AM 211016 4089136 95.09 0 712580
> 2854508 209713
> 6 0 0.00
> 04:02:03 AM 207828 4092324 95.17 0 715180
> 2854596 209713
> 6 0 0.00
> 04:04:30 AM 2581956 1718196 39.96 0 662320
> 874536 209713
> 6 0 0.00
> 04:05:30 AM 4013000 287152 6.68 0 27012
> 84084 209713
> 6 0 0.00
>
> 2. sar -f sa09 -R
>
> 03:53:43 AM frmpg/s shmpg/s bufpg/s campg/s
> 03:54:43 AM -263.02 0.00 91.67 299.50
> 03:55:43 AM -63.35 0.00 121.40 0.80
> 03:56:43 AM -272.18 0.00 68.13 276.32
> 03:57:43 AM -415.72 0.00 36.13 413.92
> 03:58:43 AM -91.03 0.00 76.95 89.65
> 03:59:43 AM 5.32 0.00 43.47 0.73
> 04:02:03 AM -4.74 0.00 3.86 0.13
> 04:04:30 AM 5013.36 0.00 -111.62 -4181.22
> 04:05:30 AM 5962.68 0.00 -2647.12 -3293.55
> 04:06:30 AM -8.10 0.00 0.02 6.50
>
> 3. sar -f sa09 -b
>
> 03:53:43 AM tps rtps wtps bread/s bwrtn/s
> 03:54:43 AM 161.52 156.32 5.20 3156.67 119.60
> 03:55:43 AM 148.37 129.35 19.02 1034.80 377.33
> 03:56:43 AM 146.32 128.48 17.83 2732.80 360.40
> 03:57:43 AM 107.32 84.62 22.70 3743.60 447.07
> 03:58:43 AM 91.73 82.03 9.70 1312.40 194.80
> 03:59:43 AM 75.62 54.22 21.40 433.73 350.00
> 04:02:03 AM 4.97 4.83 0.14 38.65 1.24
> 04:04:30 AM 82.68 9.44 73.24 78.45 958.39
> 04:05:30 AM 2.93 0.00 2.93 0.00 29.33
> 04:06:30 AM 0.22 0.00 0.22 0.00 1.73
>
> 4. sar -f sa09 -i
>
> 03:53:43 AM dentunusd file-sz %file-sz inode-sz super-sz %super-sz
> dquot-sz %dquot-sz rtsig-sz %rtsig-sz
> 03:54:43 AM 57361 134 0.01 61318 0 0.00
> 0 0.00 0 0.00
> 03:55:43 AM 58318 124 0.01 62006 0 0.00
> 0 0.00 0 0.00
> 03:56:43 AM 44384 135 0.01 47145 0 0.00
> 0 0.00 0 0.00
> 03:57:43 AM 42565 135 0.01 45983 0 0.00
> 0 0.00 0 0.00
> 03:58:43 AM 18901 134 0.01 22408 0 0.00
> 0 0.00 0 0.00
> 03:59:43 AM 607 135 0.01 1173 0 0.00
> 0 0.00 0 0.00
> 04:02:03 AM 4294967295 113 0.01 417 0
> 0.00 0 0.00 4 0.39
> 04:04:30 AM 49 247 0.02 6316 0 0.00
> 0 0.00 0 0.00
> 04:05:30 AM 121 311 0.03 365 0 0.00
> 0 0.00 0 0.00
>
> 5. sar -f sa09 -u
>
> 03:53:43 AM CPU %user %nice %system %idle
> 03:54:43 AM all 7.52 0.00 25.15 67.33
> 03:55:43 AM all 8.97 0.00 25.28 65.75
> 03:56:43 AM all 6.07 0.00 23.82 70.11
> 03:57:43 AM all 5.08 0.00 23.54 71.38
> 03:58:43 AM all 6.77 0.00 22.88 70.36
> 03:59:43 AM all 7.18 0.00 25.82 67.00
> 04:02:03 AM all 0.77 0.00 96.32 2.91
> 04:04:30 AM all 4.20 0.00 95.11 0.69
> 04:05:30 AM all 1.88 0.00 5.29 92.83
> 04:06:30 AM all 2.01 0.00 2.81 95.18
>
> Russell Coker wrote:
> >I have a server with 4G of RAM running ReiserFS for everything that
> > matters.
> >
> >It has 2G of swap space free, but so far I have not seen swap usage go
> > above 1.6M (so in normal use I could turn off swap entirely and expect
> > not to see much difference).
> >
> >When it's under really heavy load (when I have a maintenance task
> > involving a "find /" and there are lots of POP/IMAP clients hitting the
> > server as well as mail delivery) and the load average gets to about 40,
> > the "kswapd" kernel thread starts using excessive CPU time. It will stay
> > on ~4% but have spikes of up to 45%!!! This is a two-processor machine
> > so 45% CPU reported by top means 90% of a single CPU I guess. 90% of a
> > 1.8GHz P4 CPU is a lot of CPU and I think that something is wrong.
> >
> >In the meager documentation in the kernel source kswapd is described as
> > being involved in paging to disk. I don't think that this is what it is
> > doing as there is no noticable paging activity (it generally has at least
> > 600M of "buffers" so there is no real shortage of memory).
> >
> >Would the activity of kswapd be involved with ReiserFS in any way? What
> > can I do to improve this situation?
--
Dieter Nützel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: Dieter.Nuetzel at hamburg.de (replace at with @)
^ permalink raw reply
* [Printing-architecture] [Fwd: PAPI "supported" functions]
From: Norm Jacobs @ 2003-01-09 16:38 UTC (permalink / raw)
To: printing-architecture
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: Type: message/rfc822, Size: 8778 bytes --]
From: "Hastings, Tom N" <hastings@cp10.es.xerox.com>
To: Norm Jacobs <Norm.Jacobs@sun.com>
Cc: printing-spool@freestandards.org
Subject: RE: PAPI "supported" functions
Date: Wed, 4 Dec 2002 16:32:55 -0800
Message-ID: <E0BE13326C4EBC45BBC635197DEB7E3FCF0D@x-crt-es-ms1.cp10.es.xerox.com>
Norm,
This thread has been moved to [printing-spool] where it should be.
1. We liked your two functions for the Miscellaneous section.
2. Ira and I found a function in your list that isn't in the PAPI v0.9 spec:
papiServiceSetServiceName Optional API Support
3. We suggest that the papi.h file be included in the same directory as the
spec and the IPP-Object-Attributes.pdf file that is referenced from Section
9.
4. The header file should be referenced from the spec, just like the
IPP-Object-Attributes.pdf file.
5. Having the header file would also make it clear what some of the type
definitions are as well that aren't explained or defined in the spec.
6. Ira and I agree with your optional attributes, even papiJobValidate (even
though it is required in IPP). I'll update our two profiles accordingly.
7. However, in doing the review, we realized that there are a bunch of
functions in the Services section that are a mistake and should be removed.
They are the Set and Get of the individual fields of the Service object:
UserName, Password, Encryption, AuthCB, AppData, and ServiceName. Since all
of them (except AppData) are passed in the constructor, why not delete all
of the Set functions? Then provide a single Get (or Query?) function which
returns all 6 of the fields of the Service object as a structure? We think
that being able to change such fundamental things in the Service object
instance, such as UserName, Password, Authentication, is not sound.
Also having a lot of optional functions is not very useful. Application
writers won't use them, if they are optional, since they won't always be
present.
8. What did you mean by the notation "Printer Support":
papiPrinterListJobs Core Printer Support
Its the only attribute listed with "Printer Support".
Thanks,
Tom
-----Original Message-----
From: Norm Jacobs [mailto:Norm.Jacobs@sun.com]
Sent: Tuesday, December 03, 2002 15:42
To: printing-discuss@freestandards.org
Subject: [printing-meetingnotes] PAPI "supported" functions
In our last conference call, we discussed a desire to be able to
enumerate support for the various PAPI functions from a particular
PAPI implementation. Since we are not breaking down the PAPI further
into constituent components and we are requiring unsupported functions
to return PAPI_OPERATION_NOT_SUPPORTED, It's not sufficient to simply be
able to link with the library to determine support.
Assuming that we add something, the additional calls probably belong in
the
Misc. section of the spec. Anyway, here a couple of possible calls that
we could use to determine if a function is stubbed out or not.
-Norm
papiLibrarySupportedCalls()
Description
The papiLibrarySupportedCalls() function can be called to request a
list
of API functions that are supported in the implementation. Support
for a
function means that the implementation of that function is not a stub
that
simply returns PAPI_OPERATION_NOT_SUPPORTED.
Syntax
extern char **papiLibrarySupportedCalls();
Inputs
none
Outputs
none
Returns
A NULL terminated list of supported function names. This list should
not
be free'd by the caller.
papiLibrarySupportedCall()
Description
The papiLibrarySupportedCall() function can be called to determine if
a
specific API call is supported in the implementation. Support for a
function means that the implementation of that function is not a stub
that simply returns PAPI_OPERATION_NOT_SUPPORTED.
Syntax
extern char papiLibrarySupportedCall(char *name);
Inputs
name The name of the function that is being asked about
Outputs
none
Returns
A return of PAPI_TRUE indicates that the named function is supported
by
the API implementation. A return of PAPI_FALSE indicates that the the
named function is not supported by the API implementation.
Below is a list of functions in the PAPI
papiAttributeListAdd Core API Support
papiAttributeListAddString Core API Support
papiAttributeListAddInteger Core API Support
papiAttributeListAddBoolean Core API Support
papiAttributeListAddRange Core API Support
papiAttributeListAddResolution Core API Support
papiAttributeListAddDatetime Core API Support
papiAttributeListAddCollection Core API Support
papiAttributeListDelete Core API Support
papiAttributeListGet Core API Support
papiAttributeListGetString Core API Support
papiAttributeListGetInteger Core API Support
papiAttributeListGetBoolean Core API Support
papiAttributeListGetRange Core API Support
papiAttributeListGetResolution Core API Support
papiAttributeListGetDatetime Core API Support
papiAttributeListGetCollection Core API Support
papiAttributeListFree Core API Support
papiAttributeListFind Core API Support
papiAttributeListGetNext Core API Support
papiAttributeListFromString Optional API Support
papiAttributeListToString Optional API Support
papiServiceCreate Core API Support
papiServiceDestroy Core API Support
papiServiceSetUserName Optional API Support
papiServiceSetPassword Optional API Support
papiServiceSetEncryption Optional API Support
papiServiceSetAuthCB Optional API Support
papiServiceSetAppData Optional API Support
papiServiceSetServiceName Optional API Support
papiServiceGetUserName Optional API Support
papiServiceGetPassword Optional API Support
papiServiceGetEncryption Optional API Support
papiServiceGetAuthCB Optional API Support
papiServiceGetAppData Optional API Support
papiServiceGetServiceName Optional API Support
papiServiceGetStatusMessage Core API Support
papiPrintersList Core API Support
papiPrinterQuery Core API Support
papiPrinterModify Optional API Support
papiPrinterPause Optional API Support
papiPrinterResume Optional API Support
papiPrinterPurgeJobs Optional API Support
papiPrinterListJobs Core Printer Support
papiPrinterGetAttributeList Core API Support
papiPrinterFree Core API Support
papiJobSubmit Core Job Support
papiJobSubmitByReference Core Job Support
papiJobValidate Optional Job Support
papiJobStreamOpen Core Job Support
papiJobStreamWrite Core Job Support
papiJobStreamClose Core Job Support
papiJobQuery Core Job Support
papiJobModify Optional Job Support
papiJobCancel Core Job Support
papiJobHold Optional Job Support
papiJobRelease Optional Job Support
papiJobRestart Optional Job Support
papiJobGetAttributeList Core Job Support
papiJobGetPrinterName Core Job Support
papiJobGetID Core Job Support
papiJobGetJobTicket Optional Job Support
papiJobFree Core Job Support
papiJobListFree Core Job Support
papiStatusString Core API Support
papiLibrarySupportedCalls Core API Support
papiLibrarySupportedCall Core API Support
_______________________________________________
printing-discuss mailing list
printing-discuss@freestandards.org
http://base.freestandards.org/mailman/listinfo/printing-discuss
^ permalink raw reply
* Re: [PATCH] PATCH: IPMI driver
From: Dave Jones @ 2003-01-09 16:44 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: alan
In-Reply-To: <200301090332.h093WML05981@hera.kernel.org>
> ChangeSet 1.980, 2003/01/08 22:23:15-02:00, alan@lxorguk.ukuu.org.uk
>
> [PATCH] PATCH: IPMI driver
>
> This has been in -ac for a short while. Linus accepted and merged the
> same IPMI support into 2.5.54 so now it can move into 2.4 IMHO
>
> Documentation/IPMI.txt | 341 ++++++
> drivers/char/Makefile | 5
> drivers/char/ipmi/Makefile | 20
> drivers/char/ipmi/ipmi_devintf.c | 532 ++++++++++
> drivers/char/ipmi/ipmi_kcs_intf.c | 1235 ++++++++++++++++++++++++
> drivers/char/ipmi/ipmi_kcs_sm.c | 467 +++++++++
> drivers/char/ipmi/ipmi_kcs_sm.h | 70 +
> drivers/char/ipmi/ipmi_msghandler.c | 1811 ++++++++++++++++++++++++++++++++++++
> drivers/char/ipmi/ipmi_watchdog.c | 971 +++++++++++++++++++
> include/linux/ipmi.h | 516 ++++++++++
> include/linux/ipmi_msgdefs.h | 58 +
> include/linux/ipmi_smi.h | 144 ++
> 12 files changed, 6170 insertions(+)
Either I'm blind, or none of those files exist in Linus' tree
looking at current bitkeeper snapshot.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: Help! AMD Config Advice
From: Eli Carter @ 2003-01-09 17:08 UTC (permalink / raw)
To: f.callaghan; +Cc: LinuxMTD
In-Reply-To: <200301091146.13337.f.callaghan@ieee.org>
Frank R Callaghan wrote:
> Is there no solution to this question ?
> am I asking the wronge group ?
> is it so stupid it does not deserve a responce ?
>
> ---------- Forwarded Message ----------
>
> Subject: AMD Config Advice
> Date: Thu, 19 Dec 2002 15:31:19 -0500
> From: Frank R Callaghan <f.callaghan@ieee.org>
> To: LinuxMTD <linux-mtd@lists.infradead.org>
>
> Hi,
>
> I undrstand this may be a very basic question, but here go's
>
> I am looking to use an AMD flash chip on my pc104 card
> to store some non-volatile data, the chip is a 2MB part AMD29F016,
> the BIOS is in the top 128KB of the first mega-byte(do not want to
> overwrite).
>
> After setting up the kernel with MDT I get
> cat /proc/mtd
> dev: size erasesize name
> mtd0: 00200000 00010000 "Physically mapped flash"
>
> ok but I only need the second 1MB - is there some way to
> prevent the first meg being mapped/used ?
>
> Kernal Version 2.4.19 with:
[snip config]
> also I'm looking to use jffs2 as the file system - maybe I can partion it
> to only use the second meg ???
You should be able to partition the MTD device by the commandline or a
redboot table.
I believe jffs2 requires at least 5 'sectors' on the chip, though I've
not used it. You would need to check the layout of your device has
enough for it.
That's about the extent of my knowledge at the moment... I hope it gives
you enough to google on...
HTH,
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
^ permalink raw reply
* Documents on OSS-Emulation available
From: Takashi Iwai @ 2003-01-09 16:35 UTC (permalink / raw)
To: alsa-user; +Cc: alsa-devel
Hi,
I wrote a brief document to explain the OSS-emulation of ALSA on the
kernel (the default mode). The original text file is available on
alsa-kernel cvs tree (Documentation subdirectory).
The on-line version is at
http://www.alsa-project.org/~iwai/OSS-Emulation.html
ciao,
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* [parisc-linux] ibm-disk on a hp 735/125
From: Joerg Krebs @ 2003-01-09 15:08 UTC (permalink / raw)
To: mailingliste parisc-linux
Hello all,
im running a hp 735/125 with a st31200wd 1GB harddisk, connected to the
fast-wide scsi-connector, which run's quit nice.
But now I want to replace the disk with a larger 4,3GB ibm dcas-34330
disk, but I can't get it be detected by the system, I think i used the
same jumper settings as on the old seagate drive.
at the search for potential boot devices nothing appears.
So perhaps someones uses the same harddisk and can tell me the right
jumper-settings, the disk itself works fine with a normal PC with a
scsi-wide controller.
Thanks for your help
J. Krebs
--
''~``
( o o )
+------------------.oooO--(_)--Oooo.------------------+
| |
| .oooO |
| ( ) Oooo. |
+---------------------\ (----( )--------------------+
Joerg Krebs \_) ) /
Oettingenstr. 67 (_/
80538 Muenchen
Raum: Z1.16
Tel.: +49-89-2180-9251
Fax.: +49-89-2180-9202
Homepage:
http://www.bmo.physik.uni-muenchen.de/~krebs
------------------------------------------------JK
^ permalink raw reply
* Re: OT: Which Gigabit ethernet card?
From: John Bradford @ 2003-01-09 16:39 UTC (permalink / raw)
To: Bill Davidsen; +Cc: lkml, linux-kernel
In-Reply-To: <Pine.LNX.3.96.1030109111305.28217B-100000@gatekeeper.tmr.com>
> > > I would hope a decent cable tester would test for effects at useful
> > > frequency. The frequency of a battery is too low to reveal some problems.
> >
> > "Frequency of a baterry"? What the hell is that? Baterry provides direct
> > current, not alternating one... Tester provides it's own testing signals.
>
> Clearly I need to add a smiley for the humour-impared.
>
> The original post you clipped implied that all you needed was a pair of
> RJ45 sockets and a battery, which would do continuity testing only.
Which is exactly what was *required* - we were talking about
identifying crossover and non-crossover cables, which is why I
suggested the battery and LED in a spare wallplate solution, which
works perfectly.
:-)
John.
^ permalink raw reply
* [linux-lvm] UUID
From: Matt Schillinger @ 2003-01-09 16:34 UTC (permalink / raw)
To: linux-lvm
Can someone explain the UUID, etc on a volume and on VGs?
Is the UUID stored on the volume, or on the host machine?
The reason I ask, is that I have a parrallel scsi raid, which is
connected to 2 machines. If i reboot both machines, or go through a
vgexport/import procedure (while online), i can see the VGs and LVs on
both machines.. can even mount the volumes simultaneously (It was only a
test.. I understand that it is not a Shared Filesystem, and would never
do simultaneous mounts on production filesystems).
This is what I believe to be the case:
1. The UUID is stored on the volume itself, and the VG data is stored
somewhere on the disks also.
2. The import/export/activated/deactivated status of a volume is held on
the host machine.
this allows 2 machines to see the same VG/LVs.
Is this correct? And is it supported as a function of LVM, or am I in
'unsupported' territory?
--
Matt Schillinger
mschilli@vss.fsi.com
^ permalink raw reply
* Some ALSA documents on line
From: Takashi Iwai @ 2003-01-09 16:33 UTC (permalink / raw)
To: Patrick Shirkey; +Cc: alsa-devel
Hi Patrick,
could you add/update the link on ALSA web page to my documents?
now there are three documents available on line.
- Writing an ALSA Driver
http://www.alsa-project.org/~iwai/writing-an-alsa-driver/index.html
http://www.alsa-project.org/~iwai/writing-an-alsa-driver.pdf
http://www.alsa-project.org/~iwai/writing-an-alsa-driver.sgml
- ALSA Driver API Reference
http://www.alsa-project.org/~iwai/alsa-driver-api/index.html
http://www.alsa-project.org/~iwai/alsa-driver-api.pdf
http://www.alsa-project.org/~iwai/alsa-driver-api.sgml
- Notes on Kernel OSS-Emulation
http://www.alsa-project.org/~iwai/OSS-Emulation.html
all can be linked from http://www.alsa-project.org/~iwai/alsa.html#MyALSADocs
TIA.
ciao,
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* mtdram bug - module count incorect
From: Der Herr Hofrat @ 2003-01-09 17:03 UTC (permalink / raw)
To: linux-mtd
Hi !
here is how to reproduce the problem - It's due to a mistake I made, I
called mkfs.minix on the mounted filesystem - but mkfs.minix exits with
the proper error still the usage count was increased...
Kernel is 2.4.19-rtl3.2-pre1
# lsmod
Module Size Used by
de4x5 41104 1 (autoclean)
# insmod mtdcore.o
# insmod mtdram.o total_size=4096 erase_size=128
# dmesg
mtd: Giving out device 0 to mtdram test device
# lsmod
Module Size Used by
mtdblock 4884 0 (unused)
mtdram 2068 0 (unused)
mtdcore 2052 1 [mtdblock mtdram]
de4x5 41104 1 (autoclean)
# mkfs.minix /dev/mtdblock0
1376 inodes
4096 blocks
Firstdatazone=47 (47)
Zonesize=1024
Maxsize=268966912
# mount -t minix /dev/mtdblock0 /mnt
# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/mtdblock0 4049 1 4048 0% /mnt
# lsmod
Module Size Used by
mtdblock 4884 1
mtdram 2068 1
mtdcore 2052 1 [mtdblock mtdram]
de4x5 41104 1 (autoclean)
I found my mistake in the command history, and it is well reproducable.
# mkfs.minix /dev/mtdblock0
mkfs.minix: %s is mounted; will not make a filesystem here!
# lsmod
Module Size Used by
mtdblock 4884 1
mtdram 2068 2
^^^^
wrong module usage count after mkfs.
mtdcore 2052 1 [mtdblock mtdram]
de4x5 41104 1 (autoclean)
The problem is that mkfs.minix on the mounted filesystem increaesed
the modules usage count - so I guess this means the MOD_INC_.. is
somewhere in the wrong place as it is done in a failure path (or
the MOD_DEC is missing...)
If this is not a known problem I'll give it a try to trak it down.
thx !
hofrat
^ permalink raw reply
* Re: [LARTC] ECN vs. RED
From: bert hubert @ 2003-01-09 16:26 UTC (permalink / raw)
To: lartc
On Mon, Dec 30, 2002 at 11:04:08AM +0100, Thomas Jalsovsky wrote:
> So my question is: does RED works with ECN?
Yes, but you need to turn it on. See the tc sources :-(
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl Consulting
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Why is Nvidia given GPL'd code to use in non-freedrivers?
From: Edward Kuns @ 2003-01-09 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Edward Kuns
Richard Stallman (rms at gnu.org) said:
> But if that doesn't work for you, I would not consider it a great loss
> for the world if your products were not produced. They contribute
> something to the world if they are free software, but otherwise not.
Richard, you have stated eloquently and perhaps completely the divide
between the FSF and the supporters of the Open Software movement. You
have also stated quite eloquently the exact reason that an Open Software
movement exists.
You presume to speak to what is moral and ethical for everybody. You
speak as if your definition of "free" is the dictionary definition of
"free." You speak as if you alone (and those who fully toe your line)
can decide what brings value to the world.
Wow.
I, for one, put my money where my mouth is. I am squarely in the Open
Software movement. I support (with money) NVidia, Code Weavers, and in
the past, 4 Front Technologies, for example. If I were a commercial
entity in need of the technologies that Andre brings to the table, I
would gladly support his company by purchasing non-free (by your
definition) products. Note: I refused to purchase NVidia graphics
cards before the time when they released version 1.0 of their drivers.
If they ever stopped supporting their Linux drivers, I would immediately
stop purchasing their hardware. I vote with my wallet.
*I* get to decide what brings value to me and what I consider to be
freedom. Richard, you don't get to define those values for me or for
anybody else except those who *choose* to agree with your narrow
definitions.
It is true that the GNU model works for *many* large software projects.
This does not mean that it will work for *all* large software projects.
You agree with this and then say that the world would be better off by
not having those products because they would have been done in the
"usual grabbing way."
Richard, you *do* understand why people compare your views to Communism,
right? I'm not saying such opinions are accurate or inaccurate, but
Communism advocates public ownership of *all* property and you advocate
public ownership of *all* software. IMO, that is the core of the
comparison that people make and you MUST already understand that, right?
(OK, you don't advocate public ownership of software that is developed
but never distributed. Most software that concerns people in this arena
is software that is distributed, so that point is irrelevant to this
discussion. No-one here is talking about such software.)
I am glad that people are willing to produce "non-free" (by your
definition) software. I don't even always prefer "free" software to
"non-free" software. (quotes to indicate the FSF definition of "free"
is being used.) I evaluate each case, taking all options into account,
and then choose what best fits my needs. To me, THAT is freedom. We
would have substantially less freedom if the GNU project never existed,
and I acknowledge and thank all from the GNU project for their
contributions, past and present and future. HOWEVER. We would also
have substantially less freedom if *all* distributable software was
required to be GPL. (Lack of quotes to indicate that I am NOT using the
FSF definition.)
This is my opinion but also the opinion of many here. Richard, you are
not going to change people's views on this. The Open Source movement
doesn't exist just because people hadn't thought "freedom" through
completely yet. It exists, in part at least, because people rejected
the FSF definition of "freedom" after fully considering the issue.
Eddie
P.S. In the interests of moving off-topic conversions off the list, I
will not publicly respond to any replies or any more of this thread. I
*will* privately respond to any replies, whether they are posted only to
me or also to the list. I just wanted to speak up once so that my
silence could not possibly be construed by RMS or others as agreement.
If you wish a response from me, you must CC: me as I am not subscribed
to this list.
--
Eddie Kuns | Home: ekuns@kilroy.chi.il.us
--------------/ URL: (none at the moment)
"Ah, savory cheese puffs, made inedible by time and fate." -- The
Tick
^ permalink raw reply
* Re: [LARTC] My fifo Modification Qdisc
From: bert hubert @ 2003-01-09 16:23 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104197037617850@msgid-missing>
On Tue, Jan 07, 2003 at 03:11:41PM -0500, Al-Gharribeh Muhammad wrote:
> Hi,
> Actually, I did some modification on sch_fifo.c to do some required
> accumulation of packets lets say 300 packet and to dequeue them together but
> I couldn't compile the modified fifo, the question is How can I compile and
> to test my modified fifo.
Learn C :-) I suggest you start by just changing the files in place and
compiling the kernel as usual.
Regards,
bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl Consulting
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: patching iptables - how?
From: Arnt Karlsen @ 2003-01-09 16:22 UTC (permalink / raw)
To: netfilter
In-Reply-To: <20030109034250.51982.qmail@web12706.mail.yahoo.com>
On Thu, 9 Jan 2003 03:42:50 +0000 (GMT),
Mladen Meduric <mladen_meduric@yahoo.com> wrote in message
<20030109034250.51982.qmail@web12706.mail.yahoo.com>:
> Whoa!!!
>
> What a list! Thank you all very much!
> I thought on just installing 1.2.7a from scratch, but didn't know what
> effect would it have on old (1.2.5) version. Do I need to uninstall
> that one first? If yes, is it best to use Sytem->Package->uninstall or
> rpm -u
..'rpm -e iptables' will do nicely. ;-)
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
^ permalink raw reply
* Re: observations on 2.5 config screens
From: Bill Davidsen @ 2003-01-09 16:12 UTC (permalink / raw)
To: Dave Jones
Cc: Robert Love, Adrian Bunk, Robert P. J. Day,
Linux kernel mailing list
In-Reply-To: <20030109125007.GA17045@codemonkey.org.uk>
On Thu, 9 Jan 2003, Dave Jones wrote:
> On Wed, Jan 08, 2003 at 05:49:54PM -0500, Bill Davidsen wrote:
> > > SMP isn't a processor option ?
> > Clearly not, it's not processor dependent or even architecture dependent
>
> Of course its arch dependant. Some of the archs we support don't do SMP.
> See m68k for one. Sure there may be some boards out there with >1 68k
> welded to them, but Linux doesn't run on them.
Exactly, that's not a characteristic of the CPU, it's a system board thing
and support is really a low level kernel option.
> > generally. It's a characteristic of the os, unlike microcode, mtrr, and
> > other stuff not on some architectures.
>
> Absolute nonsense. These are _cpu_ features. If you dispute this,
> you have no understanding of what you talking about.
No, you missed what I was talking about... reread the above, I said SMP
was an os feature *unlike* mtrr, etc.
> > You can select it for 386/486/P5
> > (and it works in 2.4 at least, for P5, have several).
>
> And thats perfectly valid. Although I've not seen an MP compliant
> 386/486 personally, there were patches I beleive at one time for
> some of the strange 486 implementations.
>
> It's also a valid thing to do to do for code coverage reasons.
> Although I doubt anyones testing SMP builds on a 386/486 any more.
>
> > I would think that processor options would select the processor and any
> > options which are specific to it rather than generally supported. Serial
> > numbers, firmware loads, that sort of feature.
>
> serial number stuff is done at run time. Firmware loads. Well, you
> mentioned above that microcode wasn't a CPU feature, now you change
> your mind ?
>
> > Preempt and smp, are general, I guess not supported on every possible
> > hardware
>
> Again, more contradiction. Above you said of SMP:
> "Clearly not, it's not processor dependent or even architecture dependent"
> Now you're saying it is arch dependant.
In general by architecture dependent I meant "specific to one
architecture" or even one processor. HT is only on one type of CPU, mtrr
is on one family of CPUs, etc. As opposed to SMP, which is possible on any
of the supported CPUs, even if there isn't a Linux supported example of
it. There was even a board mounting two AMD Socket7 CPUs with a bunch of
glue which ran some BSD variant (no VM, I assume).
I don't mind you disagreeing with me, I'd appreciate it if you would stop
misreading what I said and then claiming I don't know I'm talking about.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.