* Re: Problem reading directories
From: Sergey Suleymanov @ 2003-01-08 7:19 UTC (permalink / raw)
To: Linux-MSDOS Mailing list
In-Reply-To: <200301080500.h0850YS02757@jupiter.dyse.net>
>>>>> José Mario Trujillo writes:
José> Hi, I'm running in a Debian Linux dosmeu 1.1.4 and Freedos 8b.
José> I tried to install a propietary aplication that creates a
José> directory tree like c:\#$COMPAC.PRO\COMPAC\ and inside create a
Is C: drive lredired linux path or hdimage? How are you
specify it in dosemu.conf?
--
Sergey Suleymanov
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: !?!
From: Russell Coker @ 2003-01-08 7:18 UTC (permalink / raw)
To: Anton Erofeevskij, reiserfs-list
In-Reply-To: <3E1BCAE6.9000408@ap-plastic.ru>
On Wed, 8 Jan 2003 07:53, Anton Erofeevskij wrote:
> in reiserfs filesystem
> time cat sd1 | ./a.out > sd2
> 0.00user 0.05system 0:01.79elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (131major+43minor)pagefaults 0swaps
>
> in ext2 filesystem
> time cat sd1 | ./a.out > sd2
> 0.00user 0.05system 0:00.95elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (131major+43minor)pagefaults 0swaps
Try mounting the ReiserFS file system with notail and it should perform a lot
better for such things.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
^ permalink raw reply
* Best HTML Parser
From: Blesson Paul @ 2003-01-08 7:13 UTC (permalink / raw)
To: apache-modules, DCOM, Linux Kernel, modssl-users, netfilter,
TEAMICE
Hi all
Which is the Best HTML Parser in C/C++
regards
Blesson Paul
Blesson Paul,
Software Engineer,
Integrated Computing Environments Ltd,
Cochin Special Economic Zone,
Cochin - 682 030, India.
Tel: +91-484-2413 083(O), +91-484-2413 096(O)
+91-481-2380 893(R)
^ permalink raw reply
* !?!
From: Anton Erofeevskij @ 2003-01-08 6:53 UTC (permalink / raw)
To: reiserfs-list
very small programm
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
main(int arg, char *argc[]){
int i;
while(1){
if(read(0,&i,4)!=4)
exit(0);
write(1,&i,4);
}
}
file sd1 - 1mb
in reiserfs filesystem
time cat sd1 | ./a.out > sd2
0.00user 0.05system 0:01.79elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (131major+43minor)pagefaults 0swaps
in ext2 filesystem
time cat sd1 | ./a.out > sd2
0.00user 0.05system 0:00.95elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (131major+43minor)pagefaults 0swaps
In what the reason?!?
sory
^ permalink raw reply
* Re: iptables u32 match code for review/testing/...
From: Don Cohen @ 2003-01-08 6:41 UTC (permalink / raw)
To: Harald Welte; +Cc: Don Cohen, netfilter-devel
In-Reply-To: <20030107185748.GV9467@sunbeam.de.gnumonks.org>
Harald Welte writes (two separate msgs):
> /* *** What's this about?
> Must fit inside union ipt_matchinfo: 16 bytes */
What do you mean by this?
That was a comment I found in one of the other match modules
(which I used as a template for this one).
I didn't understand it so I thought I better keep it and flag it.
If you don't know what it's about I guess it's safe to discard it.
> /* *** any way to allow for an arbitrary number of elements?
> for now I settle for a limit of 10 of each */
no way. At least not with the current kernel/userspace interface :(
Ok, then I'll leave it at 10x10x10 (perhaps a lot of overhead for
a single match?)
> I like the content (code/implementation/idea of having u32).
> The only issue is that it doesn't really fit into the current iptables
> architecture. Why?
> - because it is a whole classification engine on it's own
Why is this bad? I wrote it to do things I wanted to do but didn't
see how. I think that's good. If it subsumes a few others that are
out there, even better. (But it's almost certainly a lot slower than
any more specialized match, so they're still useful.)
> - because it has an arbitrary [variable] amount of match data
At the moment, a large fixed amount. I regard that as a fault of
current iptables, though.
> Those issues are not possible to resolve, unfortunately.
...
> > Was the indentation a problem? The tabs were all 8 spaces, but
> > perhaps you want wider indentation?
> no, but look at the structure definitions in your header file.
Oops. The "no" above suggests that you don't mind the narrow
indentation, in which case not only the .h file but the earlier
versions of the .c files were ok except for the few misplaced }'s.
But if you do want wide indentation (and don't mind >80 cols)
then here you go:
====
#ifndef _IPT_U32_H
#define _IPT_U32_H
#include <linux/netfilter_ipv4/ip_tables.h>
enum ipt_u32_ops
{
IPT_U32_AND,
IPT_U32_LEFTSH,
IPT_U32_RIGHTSH,
IPT_U32_AT
};
struct ipt_u32_location_element
{
u_int32_t number;
u_int8_t nextop;
};
struct ipt_u32_value_element
{
u_int32_t min;
u_int32_t max;
};
/* *** any way to allow for an arbitrary number of elements?
for now I settle for a limit of 10 of each */
#define U32MAXSIZE 10
struct ipt_u32_test
{
u_int8_t nnums;
struct ipt_u32_location_element location[U32MAXSIZE+1];
u_int8_t nvalues;
struct ipt_u32_value_element value[U32MAXSIZE+1];
};
struct ipt_u32
{
u_int8_t ntests;
struct ipt_u32_test tests[U32MAXSIZE+1];
};
#endif /*_IPT_U32_H*/
^ permalink raw reply
* linux i386 stack trace
From: Roets, Chris (Tru64&Linux support) @ 2003-01-08 6:46 UTC (permalink / raw)
To: linux-kernel
I known nothing about i386 calling conventions, but I would like to analyse a kernel stack.
I have the following stack trace :
STACK TRACE FOR TASK: 0xc4cb6000(vi)
0 schedule+770 [0xc01130e2]
1 schedule_timeout+18 [0xc0112d42]
2 do_select+513 [0xc0140a11]
3 sys_select+820 [0xc0140db4]
4 system_call+44 [0xc0106f14]
ebx: 00000001 ecx: bffff700 edx: 00000000 esi: bffff680
edi: 00000000 ebp: bffff798 eax: 0000008e ds: 002b
es: 002b eip: 4010e0ee cs: 0023 eflags: 00000202
esp: bffff630 ss: 002b
================================================================
>> dump -x 3301670612 40
0xc4cb7ed4: c4cb7f00
c4cb6000
00000000
c29f3000
0xc4cb7ee4: c4cb6000
00000000
c0274000
c02b2540
0xc4cb7ef4: 7fffffff
7fffffff
00000000
c4cb7f30
0xc4cb7f04: c0112d47 schedule_timeout+23
c29f3000
cc75e914
c4cb7f54
0xc4cb7f14: 00000000
c8dde7c4
00000001
c4cb7f90
0xc4cb7f24: 00000000
00000000
7fffffff
00000000
0xc4cb7f34: c0140a16 do_select+518
c4cb7f54
00000001
c4cb6000
0xc4cb7f44: 7fffffff
00000001
00000000
00000001
0xc4cb7f54: 00000000
c730f000
00000001
bffff684
0xc4cb7f64: c17d83ec
00000001
c0140db9 sys_select+825
00000001
can anybody point me out where the arguments and the local variables are ?
take for example
int do_select(int n, fd_set_bits *fds, long *timeout)
{
poll_table table, *wait;
int retval, i, off;
long __timeout = *timeout;
......
I t has 3 arguments and tree local variable
I would be nice to have the same for ia64
Chris
^ permalink raw reply
* Re: RH8 IDs SB16 wrong
From: pa3gcu @ 2003-01-08 6:37 UTC (permalink / raw)
To: Jack Heller, linux-hams
In-Reply-To: <3E1B9EF1.40309@worldnet.att.net>
On Wednesday 08 January 2003 03:45, Jack Heller wrote:
> I just installed a new SB16 pnp card under RH 8. and it identifies the
> card as: Ensoniq | 5880 Audio PCI
>
> Of course, this does not work and I cannot find a cure. Help.
modprobe es1371
>
> Thanks -- A Linux newbie -- Jack
--
Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/
^ permalink raw reply
* Re: Broadcom Gigabit 5703 and Bridging
From: David S. Miller @ 2003-01-08 6:58 UTC (permalink / raw)
To: sbolderoff; +Cc: Paul Schulz, linux-kernel
In-Reply-To: <20030108044155.GA1473@fuzzy.foursticks.com.au>
On Tue, 2003-01-07 at 20:41, sbolderoff@foursticks.com wrote:
> On Wed, Jan 08, 2003 at 02:52:37PM +1030, Paul Schulz wrote:
> The BCM95703A30 rev 1002 has issues with the hardware checksumming.
Really?
Can you demonstrate the problem with the 5703 without bridging?
Can you demonstrate the problem with bridging and another checksum
capable card?
Unless you can answer both those questions, I think faulting this
5703 variant is premature. It smells more like a briding bug to
me, perhaps it's corrupting the hw checksumming state of an SKB
as it passes through the bridging layer.
^ permalink raw reply
* Re: User mode drivers (Honest does not pay here ...)
From: Dmitry A. Fedorov @ 2003-01-08 6:17 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: Larry McVoy, linux-kernel
In-Reply-To: <200301080419.h084JMT10615@devserv.devel.redhat.com>
On Tue, 7 Jan 2003, Pete Zaitcev wrote:
> > I may be showing my ignorance here (won't be the first time) but this makes
> > me wonder if Linux could provide a way to do "user level drivers".
>
> It is a question often asked in comp.os.linux.development.system.
> If performance penalties and security problems are no obstacle,
Perfomance is slightly higher since there are no extra switching to
kernel and back to user space and parameters passing.
> a lot of hardware can be serviced with a user mode driver, except
> one that requires interrupts to operate. There is no way to deliver
> an interrupt safely to the user mode, because a device specific
> deactivation or ack-ing must be performed before interrupts are
Some devices (ISA based, at least) does not requires immediate interrupt
acknowledge, they are can be serviced from the user space with
interrupts and they do.
^ permalink raw reply
* Re: [2.5.54-dj1-bk] Some interesting experiences...
From: dhinds @ 2003-01-08 6:16 UTC (permalink / raw)
To: Joshua Kwan; +Cc: linux-kernel
In-Reply-To: <20030107215630.6f8bd876.joshk@ludicrus.ath.cx>
On Tue, Jan 07, 2003 at 09:56:30PM -0800, Joshua Kwan wrote:
> Ok, the problem is with scsi.h.
> In a typedef for SCSI LUNs 'u8' is used, but not defined - either
> 'typedef u_int8_t u8' outside of the struct, or changing the
> declaration to u_int8_t works. Thanks Misha...
It isn't a kernel header bug; 'u8' is defined elsewhere. I'll fix
cardmgr properly; it should not be referencing any kernel header
files.
-- Dave
^ permalink raw reply
* New Via 8233 Sound concerns
From: Nathaniel Russell @ 2003-01-08 6:07 UTC (permalink / raw)
To: alan; +Cc: linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 549 bytes --]
Hi Alan,
I figured i wouldn't bother you until after New Year's. I'm having a brnad
new problem when playing mp3 with XMMS and changing songs work's until
i start to load other program's like LimeWire and Yahoo! Messenger. All
deal with sound so i shut those off but i let XMMS keep playing
and then my audio from XMMS just shut's down and doesn't wanna play after that.
I don't know if i'm sending to many packets of audio to my sound card at
one time or if i'm just the lucky one with all the problems.
Nathaniel
CC me at reddog83@chartermi.net
[-- Attachment #2: Via 8233 Audio --]
[-- Type: TEXT/PLAIN, Size: 706 bytes --]
Linux version 2.4.20 (root@reddog) (gcc version 3.2.1) #1 Fri Dec 6 01:28:57 EST 2002
[SNIPED]
Via 686a/8233/8235 audio driver 1.9.1-ac2
PCI: Found IRQ 11 for device 00:11.5
PCI: Sharing IRQ 11 with 00:09.1
PCI: Sharing IRQ 11 with 00:0a.0
via82cxxx: Six channel audio available
PCI: Setting latency timer of device 00:11.5 to 64
ac97_codec: AC97 Audio codec, id: ICE17(ICE1232)
via82cxxx: board #1 at 0xE400, IRQ 11
via_audio: ignoring drain playback error -11
via_audio: ignoring drain playback error -11
via_audio: ignoring drain playback error -11
via_audio: ignoring drain playback error -11
via82cxxx: unknown number of channels
via82cxxx: timeout while reading AC97 codec (0x9A0000)
^ permalink raw reply
* Re: [2.5.54-dj1-bk] Some interesting experiences...
From: Joshua Kwan @ 2003-01-08 5:56 UTC (permalink / raw)
To: dhinds; +Cc: linux-kernel
In-Reply-To: <20030107204303.2dd901ca.joshk@ludicrus.ath.cx>
[-- Attachment #1: Type: text/plain, Size: 2641 bytes --]
Ok, the problem is with scsi.h.
In a typedef for SCSI LUNs 'u8' is used, but not defined - either
'typedef u_int8_t u8' outside of the struct, or changing the
declaration to u_int8_t works. Thanks Misha...
Not sure whose repository this bug belongs to, it's either
linux-dj/linux-2.5 or linux/linux-2.5. The error is at line 185 of
scsi.h.
Regards
Josh
Rabid cheeseburgers forced Joshua Kwan<joshk@ludicrus.ath.cx> to write
this on Tue, 7 Jan 2003 20:43:03-0800:
> No, it's not fixed...
>
> joshk@fuuma:~/pcmcia-cs-3.2.4$ make all
> cc -MD -O3 -Wall -Wstrict-prototypes -pipe -Wa,--no-warn
> -I../include/static -I/usr/src/linux-2.5/include -I../include
> -I../modules -c cardmgr.c In file included from cardmgr.c:200:
> /usr/src/linux-2.5/include/scsi/scsi.h:185: parse error before "u8"
> /usr/src/linux-2.5/include/scsi/scsi.h:185: warning: no semicolon at
> end of struct or union
> /usr/src/linux-2.5/include/scsi/scsi.h:186: warning: type defaults to
> `int' in declaration of `ScsiLun'
> /usr/src/linux-2.5/include/scsi/scsi.h:186: warning: data
> definition has no type or storage class
> make[1]: *** [cardmgr.o] Error 1
> make[1]: Leaving directory `/home/joshk/pcmcia-cs-3.2.4/cardmgr'
>
> But is this a problem with scsi.h itself?
>
> Regards
> Josh
>
> Rabid cheeseburgers forced dhinds <dhinds@sonic.net> to write this on
> Tue, 7 Jan 2003 17:58:01 -0800:
>
> > On Tue, Jan 07, 2003 at 05:21:46PM -0800, Joshua Kwan wrote:
> >
> > > 2. [linux-2.5] pcmcia-cs 3.2.3 will no longer build: here is the
> > > build log, pertinent details only.
> > >
> > > cc -MD -O3 -Wall -Wstrict-prototypes -pipe -Wa,--no-warn
> > > -I../include/static -I/usr/src/linux-2.5/include -I../include
> > > -I../modules -c cardmgr.c
> > > In file included from cardmgr.c:200:
> > > /usr/src/linux-2.5/include/scsi/scsi.h:185: parse error before
> > > "u8"
> >
> > This should be fixed in the current beta for 3.2.4 available from
> > http://pcmcia-cs.sourceforge.net/ftp/NEW.
> >
> > -- Dave
> > -
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
>
> --
> Joshua Kwan
> joshk@mspencer.net
> pgp public key at http://joshk.mspencer.net/pubkey_gpg.asc
>
> It's hard to keep your shirt on when you're getting something off your
> chest.
>
--
Joshua Kwan
joshk@mspencer.net
pgp public key at http://joshk.mspencer.net/pubkey_gpg.asc
It's hard to keep your shirt on when you're getting something off your
chest.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: ymfpci, big-endian, and spdif out
From: Troy Benjegerdes @ 2003-01-08 5:37 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5hof6t9ccy.wl@alsa2.suse.de>
On Tue, Jan 07, 2003 at 05:02:53PM +0100, Takashi Iwai wrote:
> At Thu, 2 Jan 2003 22:22:34 -0600,
> Troy Benjegerdes wrote:
> >
> > I have a mac G4 (running debian testing), a ymfpci card (MaxiSound
> > Fortissimo) with optical TOSlink out, and a yamaha HTR-5540 receiver with
> > digital optical TOSlink input.
> >
> > I'm trying to get xine or some other DVD player to output AC/3 sound to
> > the receiver for watching dvd's, and I have a couple of problems.
> >
> > 1) xmms (and xine 2-channel sound) works with OSS emulation, but is static
> > with native ALSA drivers. This seems like some endian problem
>
> then most likely it's a bug of alsa output plugin.
It seems the latest xmms source uses 'S16_NE' (which is S16_BE on
big-endian platforms) as the pcm format, which works correctly.
alsa-tools/acdec/output.c also has a problem.. it uses S16_LE on
big-endian platforms.
I am able to successfully open the SPDIF output and output *something*
with a commandline like:
ac3dec -D hw:0,0 -C THX.ac3
However, the hardware decoder (yamaha receiver) is getting garbled data
and plays what sounds like stacatto static.
ac3dec -C THX.ac3 gives the following:
Using PCM device 'iec958:AES0=0x2,AES1=0x82,AES2=0x0,AES3=0x2'
ALSA lib pcm_hw.c:292:(snd_pcm_hw_hw_params) SNDRV_PCM_IOCTL_HW_PARAMS
failed: No such device or address
PCM hw_params failed: No such device or address
Output open failed
Another interesting bit...
If I change S16_LE to S16_BE in output.c, now it works with regular 2
channel audio, but anything with the '-C' option gives:
Using PCM device 'hw:0,0'
Sample format non availableOutput open failed
Using PCM device 'iec958:AES0=0x2,AES1=0x82,AES2=0x0,AES3=0x2'
Sample format non availableOutput open failed
Should the alsa drive be able to byteswap SPDIF data??
--
--------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer@drgw.net
Somone asked my why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best answer:
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's why
I draw cartoons. It's my life." -- Charles Shultz
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: glibc 2.3.1: fix for the i386 inline strings code
From: Denis Zaitsev @ 2003-01-08 5:35 UTC (permalink / raw)
To: Michael Riepe; +Cc: Andreas Jaeger, Ulrich Drepper, libc-alpha, linux-gcc
In-Reply-To: <20030107194008.43255@thrai.stud.uni-hannover.de>
On Tue, Jan 07, 2003 at 07:40:08PM +0100, Michael Riepe wrote:
> On Tue, Jan 07, 2003 at 08:43:01AM +0500, Denis Zaitsev wrote:
> [...]
> > The exact problem with XtNewString is that we have the "void pointer
> > dereference" error when it is used with void* argument: XtNewString is
> > a macros which uses strcpy, whose inline variant, in turn, uses
> > __STRING_SMALL_GET(16|32), which don't cast their (str) argument to
> > (char*). The patch inserts such a casting. But this is not the
> > X-specific problem, I just met it when was compiling X. It's a
> > general error - string functions should work happily with void*
> > arguments, so __STRING_SMALL_GET macros' must not assume their (str)
> > argument can't be of type void*...
>
> To be more specific: __STRING_SMALL_GET expects the (str) argument to
> be an `unsigned char *'. Everything else will make it do funny things
> when (signed) characters have values >= 128. Since __strcpy_a_small()
> and __stpcpy_a_small() pass the pointer unmodified, they're broken as
> well.
You are right, indeed... There must be the (unsigned char*) cast.
^ permalink raw reply
* Re: kobject.h makes lilo compile break
From: Greg KH @ 2003-01-08 5:32 UTC (permalink / raw)
To: Simon Scheiwiller; +Cc: linux-kernel
In-Reply-To: <005f01c2b3f6$b66ba5b0$0400a8c0@gwaihir>
On Sat, Jan 04, 2003 at 02:39:31PM +0100, Simon Scheiwiller wrote:
> Hello
>
> When I'm compiling lilo on a machine with kernel 2.5.54, I get the following
> error:
>
>
> gcc -c -O2 -Wall -g `( if [ -r $ROOT/etc/lilo.defines ]; then cat
> $ROOT/etc/lilo.defines; else
> echo -DBDATA -DBUILTIN -DDSECS=3 -DIGNORECASE -DLBA32 -DLVM -DEVMS -DM386 -D
> ONE_SHOT -DPASS160 -DREISERFS -DREWRITE_TABLE -DSOLO_CHAIN -DVARSETUP -DVERS
> ION -DUNIFY; fi ) | sed 's/-D/-DLFC_/g'` `[ -r /usr/include/asm/boot.h ] &&
> echo -DHAS_BOOT_H` `cat mylilo.h` lilo.c
> In file included from /usr/include/linux/kobject.h:10,
> from /usr/include/linux/device.h:28,
> from /usr/include/linux/genhd.h:15,
> from common.h:20,
> from lilo.c:25:
> /usr/include/linux/list.h:323:2: warning: #warning "don't include kernel
> headers in userspace"
Um, why not heed this warning? :)
And yes, it looks like Pat got a change in to prevent kobject.h from
being included if __KERNEL__ is not set, but this is not the proper fix.
See the archives for the many discussions about not including kernel
header files in userspace programs.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] SCSI Core patches
From: Luben Tuikov @ 2003-01-08 5:13 UTC (permalink / raw)
To: Patrick Mansfield; +Cc: linux-scsi
In-Reply-To: <20030107173633.A17825@beaverton.ibm.com>
Patrick Mansfield wrote:
>
>>You must agree that the tuple (COMMAND, (lun, target, channel))
>>doesn't say as much as (COMMAND, DEVICE).
>
>
> Yes, but the current code simply sends a scsi_cmnd to the LLDD, and the
> LLDD need only reference the scsi_cmnd.
No, it doesn't necessarily have to. The advantages of
cmd->device->{lun, id, channel} far outweights
``LLDD need only reference the scsi_cmnd'',
as we've mentioned numerous times.
I think the networking code has similar well thought out abstractions.
> Having the LLDD use more data structures does not imply a better
> abstraction. Again, a better abstraction would be to use interfaces to
> get the host/channel/target/lun. This could add overhead depending on the
> implementation.
Aaaah, this seems like a lost cause. You seem to be arguing this just
because of sake of your changing your multipath code.
Why can't you just make those macros in your code and see how
it works out -- who knows, maybe you'll get a better design idea...
> I have looked into putting multipath in the block layer, I've looked at
> md, at the T3 code, and at the qlogic multi-path code. Code in the block
> layer would be interesting, but might not solve problems with char
> devices, and would need further abstractions on top of some multi-path
> in the scsi layer (someone has to find and represent the devices and
> paths, the block layer will not want to know about host/chan/target/lun,
> nor will the block layer want to know details about scsi device or
> transport errors).
And this is *not* an excuse to leave lun, target and channel into the
scsi command. A command belongs to a device, and a device belongs
to a host, which belongs to a pci bus, etc...
Remember we're talking about SCSI devices, not generic devices.
SCSI devices, as mentioned in my previous email have and have not
certain properties.
> Putting the multipath abstraction into scsi_request_fn is IMO the best way
> to go (as I've argued before) at least until other non-scsi block and
Please keep in mind what SCSI Core is all about. Please don't mix and
match.
>>Getting rid of redundancies in data design and code design is important.
>>
>
>
> As mentioned, using a scsi_device both for a list of paths and as a
> representation of scsi device duplicates data in multiple places.
We are *not* discussing multipathing here.
--
Luben
^ permalink raw reply
* Sign from God
From: Doom-Black Time-Train races into Hell with entire Mankind. @ 2003-01-08 5:12 UTC (permalink / raw)
To: linux-mm
Signs from God. The Messiah comes. We have the end of the World http://www.iboutique.de/fsur2932002133787/111.htm
Signs from God. The Messiah comes. We have the end of the World and already 3th Worldwar. The Mankind faces the Doom and as well the biggest ever experienced Holocaust. Each second Humanbeing ends up in the Pond of Fire. If the Messiah is not comming now (Jesus Christ, Son of God, King of the Jews), God will come as Devil-and Germany brought the entire Mankind into Hell. Owing to the Brandenburger Nazigate in Berlin every Human will be punished as hard as Adolf Hitler. That means Hellforever:Final Solution (Endlosung)-------
Everyone who doesnt call Mankind into Paradise has got at least the same much Guilt and Dirt at putting like Adolf Hitler an will be punished just as hard. The USA was sworn in to the Bible and is liable with the Final Solution (Endlosung) Death on the Cross forever- -------
The one who supports Wholesolemurderers and Traitors- like especially the USA and other Countries did towards Germany-will be executet as Wholesalemurderers and Traitors and sent to the Pond of Fire. Laughing Third Persons are even hardest punished by God.------
Jesus Christ is a Diamand,is our Redeemer-can release us from the Guilt and save entire Mankind from Downfall. You must get youself the Diamond. Otherwisely you may never enter Gods Kingdom. The Diamond is more prescious thanall Wealth af the World-And this Earth will leave Luzifers Kingdom ,the Evils Outer Space Hell Becouse Earth belongs to God,and Man is Gods Image-Words are stronger than all Weapons of the World- The Word remains. Then the Earth and Heaven are already gone.------
The Messias comes only if the Gospel is spread Worldwide and we have got a Rid of the forbidden Appletree with the Snake. And all Christians which pay Homage to the Lord and fulfill God`s Will can enter Paradise forever and step to Gods Glory. Signs from God is for everybody the last Key to Paradise, and thus very prescious-not to pay with Money and the last Path to Paradise for the entire Mankind.--------
The Brandenburger Nazigate in Berlin is the Hellgate of Mankind and must be pulled down immediately-----
Germany turned withe the Brandenburger Nazigate Got to Devil-Germany is therefore Nation of Kain and High Treason and brought the entire Mankind into Doom.-----
Germany has got the Worllpower to bring the entire Mankind into Hell, if there is no penalty fer the second Worldwar and the Brandenburger Nazigate in Berlin continues to be there.-----
Since the USA bombed the Craddle of Mankind (The Gulf-War USA and Irak),is the entire Mankind condemned to Hell.When God`s Children are getting bombed,pays the Mankind with the Eternal Penalty. That includes also the USA. The Irak is the Craddle of Mankind, Tiflis Euphrat the Beginning of the Bible. Adam and Eve. The one who`s the Worldpower Number 1- as it happens to the USA-has got the Main Responsibility for the whole Mankind and is liable now even with the Final Solution. Death at the Cross- Hell forever.-------
Sign from God is no Advertising,but a Message and is reputed for entire Mankind. Jesus Christ-a Diamant- is our Redeemer, can release us from the Guilt and save Mankind from the Fall!
http://www.zevo.de
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Commentary Summary:
From: Andre Hedrick @ 2003-01-08 5:18 UTC (permalink / raw)
To: linux-kernel
What we have seen is a lot of slide of hand tricks to try and force all
the hardware and software vendors to open source and give it all away.
This is not going to happen.
I tried it and had some success, but it cost me lots of money, time, legal
hassles, but now that the chipsets are modular what will happen?
The latest tricks in our bag:
GPL_ONLY
GPL_ONLY + restrictive kernel system calls.
Rants about derived works.
Is linux the sum of the drivers ?
If all the drivers were gone, what would be left?
Is linux the a derived work from the sum of the drivers?
Is the the source code not that manual to the API?
"Use the Source Luke!"
Is linux going to invoke the DMCA to prevent usage?
What will happen if any one of the developers trying to enforce copyright
under GPL, loses?
Now of to winners and losers:
Linux 2.6/3.0 kernel ships. One distribution present today or created in
the future because of politics or market forces, decides to disable the
GPL_ONLY as to allow binary modules to use all of the kernel services
unrestricted. The include all the source code and patches and follow all
the rules that each one is doing today.
Subtext: If GPL_ONLY is such a big issue for the distributions who employ
and rightfully own the works released, ship their products in this mode?
Of course they do not need to ship the patch, because it is in the kernel
tree shipped. This would add complexity to the enduser, to undo such a
deed. Would the customer switch distributions?
The subtext above describes why the GPL_ONLY will fail.
Remember, under GPL none of us can add restrictions to prevent people from
changing the content of the files redistributed. So it is a given it will
fail, once market forces are applied.
Now move into the embedded appliance space.
This will surely collapse into a black hole if they do not remove the
"GPL_ONLY" properties in the future stable release. So again market
forces are going to undo all the work everyone has tried to enforce like
this was a closed society of developers, similar to Redmond.
Now back to the issue of copyright enforcement since GPL is some what
removed from the issue at the enduser level.
Copyright only protects the actual document and not the content.
Recall my whining about "Vojtech Pavlik <vojtech@suse.cz>", during the
time when "Martin D." was running the show, and everyone jumped on me and
called me a fool for complaining about the file replacement issue?
The reality is that "Vojtech" complied with everything about Copyright
Law, and I had no case at all. What "Vojtech" did was to read my work and
created something new from the idea inside the document. For the most
part it worked just fine and functioned with the same behavior. One
difference is is I lost my copyright on the file, but the "IDEAS" were
transferred to a new file.
Oh and Vojtech, I own you a huge apology for being rude and ugly to you
over that entire series of events. If you can improve on the work, by all
means you should, and please do. I will not can, nor would I stop or
hinder progress again.
Now jump back to the so called "unpublished API", again.
Using the example above between "Vojtech" and myself, if anyone was to
create a full snapshot and create a new work(s) by extracting all the
ideas in the headers into a new set, nothing GPL or Copyright can do to
stop them. What was done is to extract the ideas, not the actual
protected work.
Moving forward with this new snapshot of the API to Linux which is not
subject to any license restrictions or copyright, like it or not that is
the fact! What does this mean in other cases? Could HURD extract all the
IDEA's from Linux and make it extinct? Who knows, but I do know that
should RMS be successfull, that binary modules and freedom are gone.
Since the IDEAS are transformed into a new work, assigned to FSF, oh it
scares me to go further. This could be a reality.
Here comes the boundary nobody wanted to find, except me!
Finding it may make it impossible to use linux for any business model.
Any model with IP or whatever you call it locked into "binary object".
Subtext: "binary object" and not a binary module.
For ease, lets make the new snapshot API "headers" licensed under LGPL.
I will stop for now as I am tired.
However this clearly explains how one can use the kernel API for a
snapshot, but the pain involved is huge.
I am not into this much pain, period.
Flame me if you want, I do not care.
Hate me if you want, I do not care.
Kick me out again, I do not care.
However, each of us should care and think about the above.
Regards,
Andre Hedrick
LAD Storage Consulting Group
^ permalink raw reply
* Re: Epson Stylus Color 300
From: Jens Schmidt @ 2003-01-08 5:09 UTC (permalink / raw)
To: Shane McKeown; +Cc: Linux Newbie
In-Reply-To: <20030107112432.58794.qmail@web9607.mail.yahoo.com>
Hi Shane,
go to : http://www.epson.de/eng/support/download/index_drivers.htm
that's the source for Epson drivers
Good Luck, Jens
Shane McKeown wrote:
> I am trying to get my printer working under Linux
> Mandrake 9, currently it is printing in black&white
> only, cannot get colour printing at all.
> I have installed the driver that comes with Mandrake 9
> is there another driver that I can try, or what can
> I try next
>
> Thanks for any help
>
> Shane McKeown
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* pipe bandwidth 75% higher on 2.2 than recent 2.[45]
From: rwhron @ 2003-01-08 5:22 UTC (permalink / raw)
To: linux-kernel
LMbench bw_pipe on uniprocessor K6/2 says pipe
bandwidth is about 75% higher on 2.2.23 than other
recent kernels:
kernel Pipe Bandwidth MB/sec
------------------ -------
2.2.23 115.62
2.4.20-rmap15b 66.90
2.4.21-pre1 67.07
2.4.21-pre2-jam2 70.23
2.4.21-pre2aa2 67.44
2.5.51-mm2 60.71
2.5.54-mm3 64.86
Some other benchmarks at:
http://home.earthlink.net/~rwhron/kernel/latest.html
--
Randy Hron
http://home.earthlink.net/~rwhron/kernel/bigbox.html
^ permalink raw reply
* Re: [PATCH] [2.5] IRQ distribution in the 2.5.52 kernel
From: Greg KH @ 2003-01-08 5:11 UTC (permalink / raw)
To: Kamble, Nitin A
Cc: linux-kernel, Saxena, Sunil, Mallick, Asit K, Nakajima, Jun
In-Reply-To: <E88224AA79D2744187E7854CA8D9131DA5CE52@fmsmsx407.fm.intel.com>
On Tue, Jan 07, 2003 at 06:52:59PM -0800, Kamble, Nitin A wrote:
> +# define MIN(a,b) (((a) < (b)) ? (a) : (b))
> +# define MAX(a,b) (((a) > (b)) ? (a) : (b))
There are alread definitions for min() and max(), it would be good to
use them and not try to define your own.
thanks,
greg k-h
^ permalink raw reply
* IDE DMA disabled with via82cxxx on kernels >= 2.5.35
From: rwhron @ 2003-01-08 5:16 UTC (permalink / raw)
To: linux-kernel
I have two machines with VIA chipsets. Recent 2.5
kernels boot with "DMA disabled".
On Athlon, hdparm -tT /dev/hda is about 8 times higher
on 2.4 than 2.5 kernels. hdparm -i says dma is (on) though.
I tried CONFIG_BLK_DEV_IDEDMA_FORCED=y, but that didn't
eliminated the "DMA disabled" message. Other IDE settings are:
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y
boot message:
VP_IDE: IDE controller at PCI slot 00:07.1
VP_IDE: chipset revision 6
VP_IDE: not 100%% native mode: will probe irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio
hda: IC35L040AVER07-0, ATA DISK drive
hda: IRQ probe failed (0xffffffba)
hda: DMA disabled
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586B PIPC Bus Master IDE (rev 06)
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
I also have a K6/2 with a VIA chipset. 2.5.34 and earlier were fine.
2.5.34-mm4 and subsequent 2.5.x kernels boot with "DMA disabled".
lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 47)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
The K6/2 boots with:
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 00:07.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c586b (rev 47) IDE UDMA33 controller on pci00:07.1
ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA
hda: Maxtor 51536U3, ATA DISK drive
hdb: ATAPI CDROM, ATAPI CD/DVD-ROM drive
hda: DMA disabled
hdb: DMA disabled
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
--
Randy Hron
http://home.earthlink.net/~rwhron/kernel/bigbox.html
^ permalink raw reply
* Re: [Linux-fbdev-devel] [RFC][PATCH][FBDEV]: Setting fbcon's windows size
From: Antonino Daplas @ 2003-01-08 5:02 UTC (permalink / raw)
To: James Simmons; +Cc: Linux Fbdev development list, Linux Kernel List
In-Reply-To: <1041864838.955.68.camel@localhost.localdomain>
Hi James,
Here's an improved GTF implementation. I was a bit delayed because I
was trying to find a way to do square roots without using floating
point. The diff is against linux-2.5.54 + your latest fbdev.diff.
static int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo
*var, struct fb_info *info);
if flags == 0: maximize timings
1: vrefresh rate driven calculation
2. hscan rate driven calculation
3. pixelclock driven calculation.
The parameter 'val' depends on the parameter 'flags': ignored if flags
== 0, in Hz if 1 and 2, in picoseconds if 3.
The flags are useful for cases such as a fixed-frequency monitor (pass
flags = 2) or for hardware which only have several sets of dotclocks to
use. In this case, it will run the GTF first, get the resulting
pixelclock to select a dotclock from the driver's own set, then rerun
the GTF using flags=3, and val = selected dotclock.
Probably still has precision errors, like converting KHZ to picoseconds,
but is more or less usable. Tested with i810fb and rivafb. (For rivafb,
I have to use a hacked version. The latest one does not work for the
riva128).
BTW, I downloaded the source code of read-edid, and it seems that the
following monitor limits are parsable from the EDID block: HorizSync,
VertRefresh, DotClock, and GTF capability. We may change info->monspecs
to match that. Also, the EDID contains a list of supported modes, but
there's only 4 of them(?).
Tony
diff -Naur linux-2.5.54/drivers/video/fbmon.c linux/drivers/video/fbmon.c
--- linux-2.5.54/drivers/video/fbmon.c 2003-01-08 04:19:48.000000000 +0000
+++ linux/drivers/video/fbmon.c 2003-01-08 04:18:11.000000000 +0000
@@ -289,7 +289,376 @@
}
#endif
+/*
+ * VESA Generalized Timing Formula (GTF)
+ */
+
+#define FLYBACK 550
+#define V_FRONTPORCH 1
+#define H_OFFSET 40
+#define H_SCALEFACTOR 20
+#define H_BLANKSCALE 128
+#define H_GRADIENT 600
+#define C_VAL 30
+#define M_VAL 300
+
+struct __fb_timings {
+ u32 dclk;
+ u32 hfreq;
+ u32 vfreq;
+ u32 hactive;
+ u32 vactive;
+ u32 hblank;
+ u32 vblank;
+ u32 htotal;
+ u32 vtotal;
+};
+
+/*
+ * a simple function to get the square root of integers
+ */
+static u32 fb_sqrt(int x)
+{
+ register int op, res, one;
+
+ op = x;
+ res = 0;
+
+ one = 1 << 30;
+ while (one > op) one >>= 2;
+
+ while (one != 0) {
+ if (op >= res + one) {
+ op = op - (res + one);
+ res = res + 2 * one;
+ }
+ res /= 2;
+ one /= 4;
+ }
+ return((u32) res);
+}
+
+/**
+ * fb_get_vblank - get vertical blank time
+ * @hfreq: horizontal freq
+ *
+ * DESCRIPTION:
+ * vblank = right_margin + vsync_len + left_margin
+ *
+ * given: right_margin = 1 (V_FRONTPORCH)
+ * vsync_len = 3
+ * flyback = 550
+ *
+ * flyback * hfreq
+ * left_margin = --------------- - vsync_len
+ * 1000000
+ */
+static u32 fb_get_vblank(u32 hfreq)
+{
+ u32 vblank;
+
+ vblank = (hfreq * FLYBACK)/1000;
+ vblank = (vblank + 500)/1000;
+ return (vblank + V_FRONTPORCH);
+}
+
+/**
+ * fb_get_hblank_by_freq - get horizontal blank time given hfreq
+ * @hfreq: horizontal freq
+ * @xres: horizontal resolution in pixels
+ *
+ * DESCRIPTION:
+ *
+ * xres * duty_cycle
+ * hblank = ------------------
+ * 100 - duty_cycle
+ *
+ * duty cycle = percent of htotal assigned to inactive display
+ * duty cycle = C - (M/Hfreq)
+ *
+ * where: C = ((offset - scale factor) * blank_scale)
+ * -------------------------------------- + scale factor
+ * 256
+ * M = blank_scale * gradient
+ *
+ */
+static u32 fb_get_hblank_by_hfreq(u32 hfreq, u32 xres)
+{
+ u32 c_val, m_val, duty_cycle, hblank;
+
+ c_val = (((H_OFFSET - H_SCALEFACTOR) * H_BLANKSCALE)/256 +
+ H_SCALEFACTOR) * 1000;
+ m_val = (H_BLANKSCALE * H_GRADIENT)/256;
+ m_val = (m_val * 1000000)/hfreq;
+ duty_cycle = c_val - m_val;
+ hblank = (xres * duty_cycle)/(100000 - duty_cycle);
+ return (hblank);
+}
+
+/**
+ * fb_get_hblank_by_dclk - get horizontal blank time given pixelclock
+ * @dclk: pixelclock in Hz
+ * @xres: horizontal resolution in pixels
+ *
+ * DESCRIPTION:
+ *
+ * xres * duty_cycle
+ * hblank = ------------------
+ * 100 - duty_cycle
+ *
+ * duty cycle = percent of htotal assigned to inactive display
+ * duty cycle = C - (M * h_period)
+ *
+ * where: h_period = SQRT(100 - C + (0.4 * xres * M)/dclk) + C - 100
+ * -----------------------------------------------
+ * 2 * M
+ * M = 300;
+ * C = 30;
+
+ */
+static u32 fb_get_hblank_by_dclk(u32 dclk, u32 xres)
+{
+ u32 duty_cycle, h_period, hblank;;
+
+ dclk /= 1000;
+ h_period = 100 - C_VAL;
+ h_period *= h_period;
+ h_period += (M_VAL * xres * 2 * 1000)/(5 * dclk);
+ h_period *=10000;
+
+ h_period = fb_sqrt((int) h_period);
+ h_period -= (100 - C_VAL) * 100;
+ h_period *= 1000;
+ h_period /= 2 * M_VAL;
+
+ duty_cycle = C_VAL * 1000 - (M_VAL * h_period)/100;
+ hblank = (xres * duty_cycle)/(100000 - duty_cycle) + 8;
+ hblank &= ~15;
+ return (hblank);
+}
+
+/**
+ * fb_get_hfreq - estimate hsync
+ * @vfreq: vertical refresh rate
+ * @yres: vertical resolution
+ *
+ * DESCRIPTION:
+ *
+ * (yres + front_port) * vfreq * 1000000
+ * hfreq = -------------------------------------
+ * (1000000 - (vfreq * FLYBACK)
+ *
+ */
+
+static u32 fb_get_hfreq(u32 vfreq, u32 yres)
+{
+ u32 divisor, hfreq;
+
+ divisor = (1000000 - (vfreq * FLYBACK))/1000;
+ hfreq = (yres + V_FRONTPORCH) * vfreq * 1000;
+ return (hfreq/divisor);
+}
+
+static void fb_timings_vfreq(struct __fb_timings *timings)
+{
+ timings->hfreq = fb_get_hfreq(timings->vfreq, timings->vactive);
+ timings->vblank = fb_get_vblank(timings->hfreq);
+ timings->vtotal = timings->vactive + timings->vblank;
+ timings->hblank = fb_get_hblank_by_hfreq(timings->hfreq,
+ timings->hactive);
+ timings->htotal = timings->hactive + timings->hblank;
+ timings->dclk = timings->htotal * timings->hfreq;
+}
+
+static void fb_timings_hfreq(struct __fb_timings *timings)
+{
+ timings->vblank = fb_get_vblank(timings->hfreq);
+ timings->vtotal = timings->vactive + timings->vblank;
+ timings->vfreq = timings->hfreq/timings->vtotal;
+ timings->hblank = fb_get_hblank_by_hfreq(timings->hfreq,
+ timings->hactive);
+ timings->htotal = timings->hactive + timings->hblank;
+ timings->dclk = timings->htotal * timings->hfreq;
+}
+
+static void fb_timings_dclk(struct __fb_timings *timings)
+{
+ timings->hblank = fb_get_hblank_by_dclk(timings->dclk,
+ timings->hactive);
+ timings->htotal = timings->hactive + timings->hblank;
+ timings->hfreq = timings->dclk/timings->htotal;
+ timings->vblank = fb_get_vblank(timings->hfreq);
+ timings->vtotal = timings->vactive + timings->vblank;
+ timings->vfreq = timings->hfreq/timings->vtotal;
+}
+
+/*
+ * fb_get_mode - calculates video mode using VESA GTF
+ * @flags: if: 0 - maximize vertical refresh rate
+ * 1 - vrefresh-driven calculation;
+ * 2 - hscan-driven calculation;
+ * 3 - pixelclock-driven calculation;
+ * @val: depending on @flags, ignored, vrefresh, hsync or pixelclock
+ * @var: pointer to fb_var_screeninfo
+ * @info: pointer to fb_info
+ *
+ * DESCRIPTION:
+ * Calculates video mode based on monitor specs using VESA GTF.
+ * The GTF is best for VESA GTF compliant monitors but is
+ * specifically formulated to work for older monitors as well.
+ *
+ * If @flag==0, the function will attempt to maximize the
+ * refresh rate. Otherwise, it will calculate timings based on
+ * the flag and accompanying value.
+ *
+ * All calculations are based on the VESA GTF Spreadsheet
+ * available at VESA's public ftp (http://www.vesa.org).
+ *
+ * NOTES:
+ * The timings generated by the GTF will be different from VESA
+ * DMT. It might be a good idea to keep a table of standard
+ * VESA modes as well. The GTF may also not work for some displays,
+ * such as, and especially, analog TV.
+ *
+ * REQUIRES:
+ * A valid info->monspecs, otherwise 'safe numbers' will be used.
+ */
+int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo *var, struct fb_info *info)
+{
+ struct __fb_timings timings;
+ u32 interlace = 1, dscan = 1;
+ u32 hfmin, hfmax, vfmin, vfmax;
+
+ /*
+ * If monspecs are invalid, use values that are enough
+ * for 640x480@60
+ */
+ if ((!info->monspecs.hfmax && !info->monspecs.vfmax) ||
+ info->monspecs.hfmax < info->monspecs.hfmin ||
+ info->monspecs.vfmax < info->monspecs.vfmin) {
+ hfmin = 29000; hfmax = 30000;
+ vfmin = 60; vfmax = 60;
+ } else {
+ hfmin = info->monspecs.hfmin;
+ hfmax = info->monspecs.hfmax;
+ vfmin = info->monspecs.vfmin;
+ vfmax = info->monspecs.vfmax;
+ }
+
+ memset(&timings, 0, sizeof(struct __fb_timings));
+ timings.hactive = var->xres;
+ timings.vactive = var->yres;
+ if (var->vmode & FB_VMODE_INTERLACED) {
+ timings.vactive /= 2;
+ interlace = 2;
+ }
+ if (var->vmode & FB_VMODE_DOUBLE) {
+ timings.vactive *= 2;
+ dscan = 2;
+ }
+
+ switch (flags) {
+ case 0: /* maximize refresh rate */
+ timings.hfreq = hfmax;
+ fb_timings_hfreq(&timings);
+ if (timings.vfreq > vfmax) {
+ timings.vfreq = vfmax;
+ fb_timings_vfreq(&timings);
+ }
+ break;
+ case 1: /* vrefresh driven */
+ timings.vfreq = val;
+ fb_timings_vfreq(&timings);
+ break;
+ case 2: /* hsync driven */
+ timings.hfreq = val;
+ fb_timings_hfreq(&timings);
+ break;
+ case 3: /* pixelclock driven */
+ timings.dclk = PICOS2KHZ(val) * 1000;
+ fb_timings_dclk(&timings);
+ break;
+ default:
+ return -EINVAL;
+
+ }
+
+ if (timings.vfreq < vfmin || timings.vfreq > vfmax ||
+ timings.hfreq < hfmin || timings.hfreq > hfmax)
+ return -EINVAL;
+
+
+ var->pixclock = KHZ2PICOS(timings.dclk/1000);
+ var->hsync_len = (timings.htotal * 8)/100;
+ var->right_margin = (timings.hblank/2) - var->hsync_len;
+ var->left_margin = timings.hblank - var->right_margin - var->hsync_len;
+
+ var->vsync_len = (3 * interlace)/dscan;
+ var->lower_margin = (1 * interlace)/dscan;
+ var->upper_margin = (timings.vblank * interlace)/dscan -
+ (var->vsync_len + var->lower_margin);
+
+ return 0;
+}
+
+/*
+ * fb_validate_mode - validates var against monitor capabilities
+ * @var: pointer to fb_var_screeninfo
+ * @info: pointer to fb_info
+ *
+ * DESCRIPTION:
+ * Validates video mode against monitor capabilities specified in
+ * info->monspecs.
+ *
+ * REQUIRES:
+ * A valid info->monspecs.
+ */
+int fb_validate_mode(struct fb_var_screeninfo *var, struct fb_info *info)
+{
+ u32 hfreq, vfreq, htotal, vtotal, pixclock;
+ u32 hfmin, hfmax, vfmin, vfmax;
+
+ /*
+ * If monspecs are invalid, use values that are enough
+ * for 640x480@60
+ */
+ if ((!info->monspecs.hfmax && !info->monspecs.vfmax) ||
+ info->monspecs.hfmax < info->monspecs.hfmin ||
+ info->monspecs.vfmax < info->monspecs.vfmin) {
+ hfmin = 29000; hfmax = 30000;
+ vfmin = 60; vfmax = 60;
+ } else {
+ hfmin = info->monspecs.hfmin;
+ hfmax = info->monspecs.hfmax;
+ vfmin = info->monspecs.vfmin;
+ vfmax = info->monspecs.vfmax;
+ }
+
+ if (!var->pixclock)
+ return -EINVAL;
+ pixclock = PICOS2KHZ(var->pixclock) * 1000;
+
+ htotal = var->xres + var->right_margin + var->hsync_len +
+ var->left_margin;
+ vtotal = var->yres + var->lower_margin + var->vsync_len +
+ var->upper_margin;
+
+ if (var->vmode & FB_VMODE_INTERLACED)
+ vtotal /= 2;
+ if (var->vmode & FB_VMODE_DOUBLE)
+ vtotal *= 2;
+
+ hfreq = pixclock/htotal;
+ vfreq = hfreq/vtotal;
+
+ return (vfreq < vfmin || vfreq > vfmax ||
+ hfreq < hfmin || hfreq > hfmax) ?
+ -EINVAL : 0;
+}
+
EXPORT_SYMBOL(parse_edid);
#ifdef CONFIG_PCI
EXPORT_SYMBOL(get_EDID);
#endif
+EXPORT_SYMBOL(fb_get_mode);
+EXPORT_SYMBOL(fb_validate_mode);
diff -Naur linux-2.5.54/include/linux/fb.h linux/include/linux/fb.h
--- linux-2.5.54/include/linux/fb.h 2003-01-08 04:20:07.000000000 +0000
+++ linux/include/linux/fb.h 2003-01-08 04:19:26.000000000 +0000
@@ -468,6 +468,10 @@
extern int fbmon_valid_timings(u_int pixclock, u_int htotal, u_int vtotal,
const struct fb_info *fb_info);
extern int fbmon_dpms(const struct fb_info *fb_info);
+extern int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo *var,
+ struct fb_info *info);
+extern int fb_validate_mode(struct fb_var_screeninfo *var,
+ struct fb_info *info);
/* drivers/video/fbcmap.c */
extern int fb_alloc_cmap(struct fb_cmap *cmap, int len, int transp);
^ permalink raw reply
* Problem reading directories
From: @ 2003-01-08 5:00 UTC (permalink / raw)
To: linux-msdos
Hi,
I'm running in a Debian Linux dosmeu 1.1.4 and Freedos 8b.
I tried to install a propietary aplication that creates a directory
tree like
c:\#$COMPAC.PRO\COMPAC\ and inside create a file which contains the
license key.
But at time of reading the license file, this apear that don't exist,
but it does.
I write a small program that simulates this, and i confirm that the
trouble is at the reading of a file under a directory with extrange
caracters in their name.
I made test which Freedos and ms-dos 6.22.
Some ideas???
excuse my english
José Mario Trujillo.
^ permalink raw reply
* FYI: issue resolved in -dj
From: Joshua Kwan @ 2003-01-08 5:08 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
just fyi (orig by me):
> 1. [linux-dj] (i think?) after pulling linux-dj i noticed that the
> references to 'font.h' in drivers/video/console were broken. They were
> like#include "font.h" - I have fixed this to refer to the right font.h
> (#include <linux/font.h>)...
Fixed! :D
http://linux-dj.bkbits.net:8080/linux-2.5/cset@1.859?nav=index.html|ChangeSet@-1d
Regards
Josh
--
Joshua Kwan
joshk@mspencer.net
pgp public key at http://joshk.mspencer.net/pubkey_gpg.asc
It's hard to keep your shirt on when you're getting something off your
chest.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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.