* Re: rotation.
From: Antonino Daplas @ 2003-01-08 16:56 UTC (permalink / raw)
To: James Simmons
Cc: Linux Fbdev development list, Linux Kernel Mailing List,
Geert Uytterhoeven
In-Reply-To: <Pine.LNX.4.44.0301072240530.17129-100000@phoenix.infradead.org>
On Wed, 2003-01-08 at 06:44, James Simmons wrote:
>
> I'm about to implement rotation which is needed for devices like the ipaq.
> The question is do we flip the xres and yres values depending on the
> rotation or do we just alter the data that will be drawn to make the
> screen appear to rotate. How does hardware rotate view the x and y axis?
> Are they rotated or does just the data get rotated?
>
If the graphics card has hardware support for rotation, then there is
nothing to be done. It's the job of the driver if it wants to rotate
the display or not. This is similar to video overlay mirroring. What
the user app sees is the framebuffer in "normal" orientation, but what
gets displayed is mirrored.
However, as Geert mentioned, if you want to support rotation
generically, then you have to do it in the fbcon level. The driver need
not know if the display is rotated or not. All it needs to do is fill a
region with color, color expand a bitmap and move blocks of data, and
optionally 'pan' the window. Fbcon will pass the correct (ie, oriented)
information for the driver.
This will not be too processor intensive as long as some data is
prepared beforehand, like a rotated fontdata.
The main difficulty with this approach is how do you tell the console to
rotate the display? We cannot use fbset because the changes will not be
visible to fbcon.
I submitted a patch before (see fbdev archives for "Console Rotation"
thread) that rotates the console this way. I had vga16fb, vesafb, and
i810fb rotate the display without any driver code change. Display
panning was also supported.
However, because we use mmap to expose the framebuffer memory, we will
not be able to completely support rotation for user applications. They
have to do it on their own.
Tony
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Corruption on mangle/INPUT when MARKing packets
From: Harald Welte @ 2003-01-08 17:07 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Costa Tsaousis, netfilter-devel
In-Reply-To: <3E19AE4F.5020908@trash.net>
[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]
On Mon, Jan 06, 2003 at 05:26:55PM +0100, Patrick McHardy wrote:
> I think the problem lies within ip_route_me_harder. It is called on
> mangled packets in the INPUT chain
> and changes skb->dst with new route after setting key.src = 0 if it's
> not a local address.
well spotted. This is exactly the problem.
So the question is: Do we really need to call route_me_harder() in the
INPUT chain? We could argue that if somebody wants to do a change
affecting the routing decision should make that change before the
routing decison, not after it.
If we agree on this change, the solution is easy. Just call
ipt_route_hook() instead of ipt_local_hook() at NF_IP_LOCAL_IN.
Otherwise we'd need a seperate route_me_harder function for the case of
non-local packets. But I don't think this makes sense at all.
Patch attached (and put into 'pending').
Thanks.
> Regards,
> Patrick
--
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: /var/lib/nfs/sm/ files
From: Christian Reis @ 2003-01-08 17:14 UTC (permalink / raw)
To: Trond Myklebust; +Cc: NFS, linux-kernel
In-Reply-To: <200301081346.10335.trond.myklebust@fys.uio.no>
On Wed, Jan 08, 2003 at 01:46:10PM +0100, Trond Myklebust wrote:
> > - Why do most entries' mtime get updated periodically, but a few of
> > the entries go stale with time?
>
> The file should get deleted every time the client releases all locks and
> successfully manages to notify the server that it is stopping monitoring.
Aha, this makes a lot of sense. Then the leftover files I am getting are
probably a product of:
syslog:Jan 7 08:35:47 canario rpc.statd[101]: Received erroneous SM_UNMON request from canario for 192.168.99.4
syslog:Jan 7 09:09:37 canario rpc.statd[101]: Received erroneous SM_UNMON request from canario for 192.168.99.4
syslog:Jan 7 18:23:15 canario rpc.statd[101]: Received erroneous SM_UNMON request from canario for 192.168.99.4
It seems that rpc.statd itself isn't liking the request it's getting and
never forwards it to the server. I used to think these were harmless,
but now I wonder why would this be happening?
> > - Why do some of the stale entries get left over even after the
> > workstations have halted (these ones present the nfs hang issue)?
>
>
> As I've told you before: 'stale' entries, as you call them, indicate that the
(Sorry, I am apparently clueless when it gets to these details.)
> rpc.statd never managed to notify the server that it should stop monitoring.
> It indicates either the server or the client crashed before the POSIX locks
> held by the client got released, or possibly that the rpc.statd processes
> crashed (or got 'kill -9' ed).
But at least it seems that nobody has crashed - statd is running along
fine. Both server and clients run the same versions of the daemon, and
the fact that we get repeated messages (without restarting anybody)
should indicate that it is in fact running.
Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL
^ permalink raw reply
* Making this list more readable
From: Carol Anne Ogdin @ 2003-01-08 16:59 UTC (permalink / raw)
To: netfilter
[-- Attachment #1: Type: text/plain, Size: 756 bytes --]
Is there any way to change the listserv so it doesn't convert control
characters (e.g., tabs, quotes and spaces at ends of lines) to '=xx' form
of hex characters. It's hard to read. (I read the digest, so perhaps the
problem lies there, and not in the main listserv?)
Does your listserv software have a conversion table you can set that will
make things more readable?
Thanks
--Carol Anne
Examples include these from a recent digest:
> F1=3D"eth0"
> IF2=3D"eth1" (what's the "=3D" mean?)
and
with the cisco's firewall enabled. If this fails, I suspect the
cisco's=20
configuration is blocking outbound replies, so you'd have to dig there.=20
(What to the trailing "=20" sequences add? They appear to be spaces in
the original message.)
[-- Attachment #2: Type: text/html, Size: 1337 bytes --]
^ permalink raw reply
* Re: [Linux-fbdev-devel] rotation.
From: Antonino Daplas @ 2003-01-08 16:56 UTC (permalink / raw)
To: James Simmons
Cc: Linux Fbdev development list, Linux Kernel Mailing List,
Geert Uytterhoeven
In-Reply-To: <Pine.LNX.4.44.0301072240530.17129-100000@phoenix.infradead.org>
On Wed, 2003-01-08 at 06:44, James Simmons wrote:
>
> I'm about to implement rotation which is needed for devices like the ipaq.
> The question is do we flip the xres and yres values depending on the
> rotation or do we just alter the data that will be drawn to make the
> screen appear to rotate. How does hardware rotate view the x and y axis?
> Are they rotated or does just the data get rotated?
>
If the graphics card has hardware support for rotation, then there is
nothing to be done. It's the job of the driver if it wants to rotate
the display or not. This is similar to video overlay mirroring. What
the user app sees is the framebuffer in "normal" orientation, but what
gets displayed is mirrored.
However, as Geert mentioned, if you want to support rotation
generically, then you have to do it in the fbcon level. The driver need
not know if the display is rotated or not. All it needs to do is fill a
region with color, color expand a bitmap and move blocks of data, and
optionally 'pan' the window. Fbcon will pass the correct (ie, oriented)
information for the driver.
This will not be too processor intensive as long as some data is
prepared beforehand, like a rotated fontdata.
The main difficulty with this approach is how do you tell the console to
rotate the display? We cannot use fbset because the changes will not be
visible to fbcon.
I submitted a patch before (see fbdev archives for "Console Rotation"
thread) that rotates the console this way. I had vga16fb, vesafb, and
i810fb rotate the display without any driver code change. Display
panning was also supported.
However, because we use mmap to expose the framebuffer memory, we will
not be able to completely support rotation for user applications. They
have to do it on their own.
Tony
^ permalink raw reply
* PrPMC800 running as NON-MONARCH
From: Anders Blomdell @ 2003-01-08 16:57 UTC (permalink / raw)
To: linuxppc embedded
I have finally managed to get our PrPMC800's running as NON-MONARCH and
using its built in Ethernet controller. Now I only have to clean up what I
have done, and remove all hardwired hacks, in order to do this, I would
like comments on the points listed below.
1. I need to find out which of the found Ethernet 82559 chips that belongs
to this card. My suggestion is to compare the Ethernet adress returned from
a "82559 PORT Dump" command with the value stored in the PrPMC800 NVRAM.
2. All Ethernet chips that are not located on the board should be left
alone, how do I do this?
3. prpmc_map_irq needs to be modified to only route interrupts from the
built in ethernet.
4. Should I add a configuration option to use the built in ethernet? There
is a potential IRQ conflict, since the 82559 will generate PCI INTB
requests, and this might lead to conflicts whith the PCI MONARCH. In our
case that is not a problem, since we got a slightly modified ADC-PMC2 from
AlphaData (http://www.alpha-data.com/), which ensures that the INTB never
reaches the PCI bus.
5. I think that it would be a good idea to add some heuristcs to find out
what kind of carrier the PrPMC800 is located on, output from the PPC-Bug
"ver;e" command on different carriers are most welcome.
Regards
Anders Blomdell
------------------------------------------------------------------------------
Anders Blomdell
Department of Automatic Control Email: anders.blomdell@control.lth.
se
Lund Institute of Technology Phone: +46 46 222 4625
Box 118, S-221 00 Lund, Sweden Fax: +46 46 138118
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [linux-lvm] problem
From: Alasdair G Kergon @ 2003-01-08 16:54 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <1042065269.12147.10.camel@tux.its.uiowa.edu>
ftp://ftp.sistina.com/pub/LVM2/tools/LVM2.1.95.14.tgz
* Allows for 'configure --disable-devmapper' if you don't have
device-mapper but just want to manipulate on-disk metadata
* Additional debug messages for devices
* Fix some 64-bit warnings
* Avoid duplicate device aliases
Alasdair
^ permalink raw reply
* Re: ipv6 stack seems to forget to send ACKs
From: Wichert Akkerman @ 2003-01-08 17:01 UTC (permalink / raw)
To: linux-kernel; +Cc: Maciej Soltysiak, netdev
In-Reply-To: <Pine.LNX.4.44.0301081718340.4542-100000@dns.toxicfilms.tv>
Previously Maciej Soltysiak wrote:
> I seem to be getting better results than you, i think that it is not an
> issue of ipv6 implementation but simply the case of time sensitive
> traffic fighting with other Internet traffic over tunnels through ipv4
> networks.
Actually, I don't follow this. How could any kind of traffic shaping
result in my client not sending ACKs, which is what the tcpdump
seems to indicate? I can understand packets being dropped which
would result in retransmits, but that is not the case here.
Wichert.
(usual I'm-no-network-guru-and-might-be-misreading-things disclaimer here)
--
Wichert Akkerman <wichert@wiggy.net> http://www.wiggy.net/
A random hacker
^ permalink raw reply
* Re: Re: [PATCH]: image.depth fix to accomodate monochrome cards
From: Geert Uytterhoeven @ 2003-01-08 16:51 UTC (permalink / raw)
To: Antonino Daplas; +Cc: James Simmons, Linux Fbdev development list
In-Reply-To: <1042043062.1003.116.camel@localhost.localdomain>
On 9 Jan 2003, Antonino Daplas wrote:
> On Wed, 2003-01-08 at 17:52, Geert Uytterhoeven wrote:
> > On 8 Jan 2003, Antonino Daplas wrote:
> > > On Wed, 2003-01-08 at 05:06, Geert Uytterhoeven wrote:
> > > > On 8 Jan 2003, Antonino Daplas wrote:
> > > > > 2. diff submitted by Geert: cleaner logo data preparation for
> > > > > monochrome cards and correct initialization of palette_cmap.transp.
> > > >
> > > > I'll have to do some more fixes there, since the monochrome logo is used not
> > > > only on monochrome displays, but on all other displays with bits_per_pixel < 4
> > > > Since the pixel data in fb_image are colormap indices, they have to reflect the
> > > > correct `black' and `white' colors on such displays.
> > > >
> > > > E.g. on amifb (which supports all bits_per_pixel from 1 through 8) the logo
> > > > showed up in black-and-blue with bits_per_pixel == 3, cfr. the first two
> > > > entries of {red,green,blue}8[] in fbcmap.c.
> > > >
> > >
> > > Hmm, I see. I think only linux_logo_bw will be the only one affected,
> > > since linux_logo_16 happens to match the console palette and in
> > > linux_logo, we either reset the palette and/or the cmap.
> >
> > Indeed.
> >
> > > Would expanding each bit to the full bit depth work? Ie for bpp=8 using
> > > monochrome data, white is 0 and black is 0xff.
> >
> > For bpp=8 that won't work, since we have 16 console colors only :-)
> >
>
> Of course :-)
>
> > But for bpp=[1-3] that's OK, cfr. fbcmap.c.
> >
> > BTW, perhaps it makes sense to just pass the appropriate `black' and `white'
> > pixel values to the logo conversion routine? Preferably through a 2-element
> > array, so we can index it with the logo data bit value instead of using
> > tests/branches. Then we'd have:
> >
>
> Something like this?
>
> static void fb_set_logo(struct fb_info *info, u8 *logo, int needs_logo)
> {
> int i, j;
> u8 mask[2] = {0,0};
>
> switch (needs_logo) {
> case 4:
> for (i = 0; i < (LOGO_W * LOGO_H)/2; i++) {
> logo[i*2] = linux_logo16[i] >> 4;
> logo[(i*2)+1] = linux_logo16[i] & 0xf;
> }
> break;
> case 1:
> case ~1:
> mask[1] = (u8) ~(BIT_SHIFT(0xffff, info->var.bits_per_pixel));
> for (i = 0; i < (LOGO_W * LOGO_H)/8; i++) {
> u8 d = linux_logo_bw[i];
> for (j = 0; j < 8; j++, d <<= 1)
> logo[i*8+j] = mask[((d ^ needs_logo) >> 7) & 1];
> }
> break;
> }
> }
Yes, looks ok.
BTW, you can get rid of the `d ^ needs_logo' inside the loop by initializing
mask[] based on the value of needs_logo.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: fb_imageblit()
From: Geert Uytterhoeven @ 2003-01-08 16:49 UTC (permalink / raw)
To: Antonino Daplas; +Cc: James Simmons, Linux Frame Buffer Device Development
In-Reply-To: <1042043058.982.115.camel@localhost.localdomain>
On 9 Jan 2003, Antonino Daplas wrote:
> On Wed, 2003-01-08 at 23:15, Geert Uytterhoeven wrote:
> > > c. Read color information from pseudopalette if directcolor/truecolor.
> >
> > Hoever, pseudopalette has entries for the first 16 colors only!
> > Hence you are limited to the 16 color for directcolor/truecolor modes.
>
> That's why there's an fb_set_logo_directpalette(), for directcolor
> visuals >= 24bpp, and fb_set_logo_truepalette(), for truecolor, in
> fb_set_logo(). Basically, it temporarily replaces info->pseudo_palette
> with one that has 256 entries to match linux_logo. Logo drawing, using
> cfb_imageblit() has always worked for me in directcolor and truecolor
> modes.
Bummer, /me should read the code more thoroughfully...
Perhaps renaming `{saved_,}palette' to `{saved_,}pseudo_palette' would make
this clearer...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: [patch 2.5] PCI: allow alternative methods for probing the BARs
From: Ivan Kokshaysky @ 2003-01-08 16:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: Alan Cox, Grant Grundler, Paul Mackerras, Benjamin Herrenschmidt,
Eric W. Biederman, davidm, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0301070942440.1913-100000@home.transmeta.com>
On Tue, Jan 07, 2003 at 09:44:53AM -0800, Linus Torvalds wrote:
> Because of legacy USB handling by the SMM BIOS, USB really ends up being a
> special case. There may be other special cases, of course, but the whole
> point of the fixups is exactly to handle special cases.
Ok, the 2-pass thing is almost done, seems to work on my
alpha and i386 boxes.
Now I have in pci_read_bases():
if (dev->skip_probe)
return;
/* Disable I/O & memory decoding while we size the BARs. */
pci_read_config_word(dev, PCI_COMMAND, &cmd);
pci_write_config_word(dev, PCI_COMMAND,
cmd & ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY));
for(pos=0; pos<howmany; pos = next) {
...
The "skip_probe" (single-bit field) can be set in the phase #1.
It's intended for stuff like pmac combo I/O ASIC, which probably
shouldn't be disabled even for a short time.
If it looks ok, I'll have a complete patch tomorrow, including
updates for all architectures and hotplug drivers.
Ivan.
^ permalink raw reply
* Re: Question for Marcelo
From: Paul P Komkoff Jr @ 2003-01-08 16:58 UTC (permalink / raw)
To: lkml
In-Reply-To: <1042036696.24099.23.camel@irongate.swansea.linux.org.uk>
Replying to Alan Cox:
> 15a wasnt working very well, the base VM isn't too bad now and its
hmm, 15b? I have some
ftp://stingr.net/pub/l/rmap15b-for-2.4.20-ac2.gz
works for me here.
> a _lot_ easier to do merging with Marcelo without rmap. The other
> related bits are seperated out but present (vm overcommit handling,
> fixed shmem, removepage callback)
*sigh*
--
Paul P 'Stingray' Komkoff Jr /// (icq)23200764 /// (http)stingr.net
This message represents the official view of the voices in my head
^ permalink raw reply
* Re: [PATCH][TRIVIAL] menuconfig color sanity
From: john slee @ 2003-01-08 16:55 UTC (permalink / raw)
To: John Bradford; +Cc: jeff-lk, linux-kernel
In-Reply-To: <200301081609.h08G929Q001835@darkstar.example.net>
On Wed, Jan 08, 2003 at 04:09:02PM +0000, John Bradford wrote:
> > using yellow and green text with a "white" background in
> > menuconfig works all right on console
>
> I have seen the original problem, where the first letter is not
> visible in an xterm.
>
> Just add a colour/monochrome toggle, that way people can choose which
> they prefer.
'export TERM=xterm-mono' works fine here
j.
--
toyota power: http://indigoid.net/
^ permalink raw reply
* RE: [linux-lvm] Graphical tool to configure LVM for RedHat 8
From: Svetoslav Slavtchev @ 2003-01-08 16:45 UTC (permalink / raw)
To: linux-lvm, Ma, Thanh(IndSys, GE Interlogix)
In-Reply-To: <55939F05720D954E9602518B77F6127F828BBA@FTWMLVEM01.e2k.ad.ge.com>
Quoting "Ma, Thanh(IndSys, GE Interlogix)" <Thanh.Ma@ge.com>:
>
>
> -----Original Message-----
> From: Anders Widman [mailto:andewid@tnonline.net]
> Sent: Wednesday, January 08, 2003 3:12 PM
> To: Linux-LVM@sistina.com
> Subject: Re: [linux-lvm] Graphical tool to configure LVM for RedHat 8
>
> * The command line tools are great but I just wonder if there is a
> graphical tool to do the same thing (for RedHat, BTW) ?
>
> I know RedHat 8 (graphical) installation has support for LVM and
> creating of LVM arrays. However, I have no idea if such tools are
> included after the installation.
> *
> * No. they are not.
>
> In any case. I do no recommend using 3rd party tools to configure and
> manage your disks.
> * What 3rd party tools can you suggest. ?
> * I guess this should be part of the FAQ as well.
>
> Thanh
try a google search for
lvmgui [java] and lvmviewer[perl i think]
both were the a bit abandend the last time i tried them,
but hopefully they'll work with RH8
may be( just may be) another solution would be
the tools provided with mandrake (diskdrake) or eventualy
the EVMS GUI (see http://evms.sf.net )
if you find some other pointers, drop a line :)
by the way SuSE had a perfect text(ncurses) installer(manager) for lvm since
SuSE 6.4 (i think about a year or two ago)
a lot of Luck,
svetljo
^ permalink raw reply
* Problem fixed: USB with vt8233a southbrigde not recognized
From: mathieu @ 2003-01-08 16:52 UTC (permalink / raw)
To: linux-kernel
I wrote yesterday about a problem with USB on vt8233a southbrigde
http://marc.theaimsgroup.com/?l=linux-kernel&m=104192831201282&w=2
I finally found out that it was a BIOS issue.
Now it's ok, and it run well. Sorry for the wasted bandwith.
Happy new year,
--
mathieu
[ http://humeur.coleumes.org : Epistémologie moderne ]
[ http://stock.coleumes.org/gpg : clef GnuPG ]
^ permalink raw reply
* USB CF reader reboots PC
From: Murray J. Root @ 2003-01-08 16:51 UTC (permalink / raw)
To: linux-kernel
ASUS P4S533 (SiS645DX chipset)
P4 2GHz
1G PC2700 RAM
SanDisk SDDR-77 ImageMate Dual Card Reader (using only CF cards)
----------------------------
devfs compiled in to kernel, devfs=nomount in lilo.conf
Insert CF card. mount it. cd to it, do reads and/or writes
umount card. remove card.
insert a different card (does not happen if the same card is used)
mount it. system reboots. logs are corrupted
Doesn't happen every time for read - sometimes I can read 2 or 3 cards first
Happens every time for write - if I write to a card then changing cards
causes a reboot
----------------------------
devfs=mount in lilo.conf
Insert CF card.
ls /dev shows sda and sda1
mount it.
ls /dev shows sda - no sda1
cd to mounted CF card
process hangs, sd-mod & usb-storage "busy"
rmmod -f usb-storage or sd-mod causes PC to stop
(keyboard & mouse unresponsive, wmfire frozen, net disconnects)
reboot
Insert CF card.
ls /dev shows sda & sda1
mount it.
ls /dev shows sda - no sda1
umount it
ls /dev shows sda - no sda1
modprobe -r sd-mod && modprobe sd-mod
ls /dev shows sda & sda1
--
Murray J. Root
------------------------------------------------
DISCLAIMER: http://www.goldmark.org/jeff/stupid-disclaimers/
------------------------------------------------
Mandrake on irc.freenode.net:
#mandrake & #mandrake-linux = help for newbies
#mdk-cooker = Mandrake Cooker
#cooker = moderated Mandrake Cooker
^ permalink raw reply
* Re: Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)
From: Vojtech Pavlik @ 2003-01-08 16:48 UTC (permalink / raw)
To: Andre Hedrick; +Cc: Roman Zippel, linux-kernel
In-Reply-To: <Pine.LNX.4.10.10301071439190.421-100000@master.linux-ide.org>
On Tue, Jan 07, 2003 at 02:45:51PM -0800, Andre Hedrick wrote:
> > Andre Hedrick wrote:
> >
> > > Please continue to think of TCP checksums as valid for a data transport,
> > > you data will be gone soon enough.
> > >
> > > Initiator == Controller
> > > Target == Disk
> > > iSCSI == cable or ribbon
> > >
> > > Please turn off the CRC on your disk drive and see if you still have data.
> >
> > This maybe works as PR, but otherwise it's crap.
>
> So, please turn off the CRC's in your onboard storage today and see how
> long it lasts.
1) Bad comparison.
2) It'd last very very long, because I never get a CRC error anyway.
--
Vojtech Pavlik
SuSE Labs
^ permalink raw reply
* Re: intel8x0: changing characteristics after an APM suspend-resume cycle
From: Takashi Iwai @ 2003-01-08 16:38 UTC (permalink / raw)
To: D. Sen; +Cc: alsa-devel
In-Reply-To: <3E1C2BAB.2020006@homemail.com>
At Wed, 08 Jan 2003 08:46:19 -0500,
D. Sen <dsen@homemail.com> wrote:
>
> Takashi Iwai wrote:
> > At Tue, 07 Jan 2003 15:40:10 -0500,
> > D. Sen <dsen@homemail.com> wrote:
> >
> >>Hi,
> >>
> >>I am using the snd-intel8x0 drivers (0.9.0rc6) on my IBM Thinkpad
> >>running Linux 2.4.20. Everything seems to run fine until the machine
> >>goes through a suspend/resume cycle when mono files/streams seem to get
> >>played back at a much faster rate.
> >>
> >>A cold reboot resolves the problem.
> >
> >
> > even after unloading/reloading the module the problem persists?
> >
> >
> > Takashi
> >
> >
>
> I just tried unloading/reloading the modules (had to close mixer
> applications, etc first). But you are right. The problem does NOT
> persist if I unload and then reload the modules.
hmm, then something lack in the resume procedure.
i guess the restoration of ac97 registers are not enough.
will take a look later.
thanks for your info!
ciao,
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: clipping
From: Antonino Daplas @ 2003-01-08 16:26 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: James Simmons, Linux Frame Buffer Device Development
In-Reply-To: <Pine.GSO.4.21.0301081053400.21171-100000@vervain.sonytel.be>
On Wed, 2003-01-08 at 17:54, Geert Uytterhoeven wrote:
> On Tue, 7 Jan 2003, James Simmons wrote:
> > > > > BTW, do we really need clipping in fb_ops.fb_{fillrect,copyarea,imageblit}()?
> > > > Personally, I don't think we need clipping. I tried removing it before
> > > > (circa linux-2.5.30+), but the console segfaults whenever I decrease
> > > > var->yres_virtual. I haven't tried this again with the newest
> > > > framebuffer framework though.
> > >
> > > Any definitive answer on this?
> > >
> > > What happens if you resize the VT to such a large size that columns*fontwidth >
> > > xres_virtual or rows*fontheight > yres_virtual? I guess clipping prevents a
> > > crash there?
> >
> > Correct. Actually fbcon_resize checks to make sure the user doesn't do
> > something stupid like this. So we might not needed. Hm.
>
> And what if you use fbset to reduce the resolution below what's needed to
> accomodate the current console size?
>
Then we do need clipping :-) I think that happened to me, I just did
not recognize it. I accidentally lowered the window size using fbset,
and suddenly I had a console where the tail end of each row of text
wraps to the next row. I wasn't using cfb_imageblit then so this was
done by hardware. If I was using cfb_imageblit, this will be clipped.
So, I think we do need clipping, but instead of implementing it in
fb_{fillrect,copyarea,imageblit}, we implement it higher up, in
accel_putcs() and family. This should also protect drivers using
hardware-based drawing.
So perhaps, a function something like this:
void fb_clip(struct fb_fillrect *region, struct fb_fillrect *clip);
This should not be difficult to implement, and I'll code it if everyone
agrees.
The other option (which I don't like) is just to check the passed
fb_var_screeninfo in the put_var ioctl against the current console
window size. But this is not foolproof as we will not be sure of the
resulting window size _after_ the fb_set_var() call.
Tony
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: [PATCH] AGP 4/7: add generic print of AGP version & mode
From: Ingo Oeser @ 2003-01-08 16:11 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-kernel
In-Reply-To: <200301071338.17372.bjorn_helgaas@hp.com>
Hi Bjorn,
hi lkml,
On Tue, Jan 07, 2003 at 01:38:17PM -0700, Bjorn Helgaas wrote:
> diff -Nru a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
> --- a/drivers/char/agp/generic.c Tue Jan 7 12:52:25 2003
> +++ b/drivers/char/agp/generic.c Tue Jan 7 12:52:25 2003
> @@ -314,15 +314,22 @@
>
> /* Generic Agp routines - Start */
>
> -void agp_device_command(u32 command)
> +void agp_device_command(u32 command, int agp_v3)
Why not agp_version?
> {
> struct pci_dev *device;
> + int mode;
> +
> + mode = command & 0x7;
> + if (agp_v3)
> + mode *= 4;
>
> pci_for_each_dev(device) {
> u8 agp = pci_find_capability(device, PCI_CAP_ID_AGP);
> if (!agp)
> continue;
>
> + printk(KERN_INFO PFX "Putting AGP V%d device at %s into %dx mode\n",
> + agp_v3 ? 3 : 2, device->slot_name, mode);
Why not use agp_version directly here?
> pci_write_config_dword(device, agp + 8, command);
> }
> }
And always supply AGP_VERSION_1, AGP_VERSION_2, AGP_VERSION_3 and
so or simply numbers to that command?
This offers a lot of possibilities:
- Version checking (drivers can deny commands not suitable for
this interface, if this checking is enabled)
- Support for AGP_VERSION_4 can be implemented without
obfuscating the interface for older (non-compliant) drivers.
- One check less ;-)
- Cleaner Code
Regards
Ingo Oeser
--
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
^ permalink raw reply
* Re: Re: [PATCH]: image.depth fix to accomodate monochrome cards
From: Antonino Daplas @ 2003-01-08 16:25 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: James Simmons, Linux Fbdev development list
In-Reply-To: <Pine.GSO.4.21.0301081045090.21171-100000@vervain.sonytel.be>
On Wed, 2003-01-08 at 17:52, Geert Uytterhoeven wrote:
> On 8 Jan 2003, Antonino Daplas wrote:
> > On Wed, 2003-01-08 at 05:06, Geert Uytterhoeven wrote:
> > > On 8 Jan 2003, Antonino Daplas wrote:
> > > > 2. diff submitted by Geert: cleaner logo data preparation for
> > > > monochrome cards and correct initialization of palette_cmap.transp.
> > >
> > > I'll have to do some more fixes there, since the monochrome logo is used not
> > > only on monochrome displays, but on all other displays with bits_per_pixel < 4
> > > Since the pixel data in fb_image are colormap indices, they have to reflect the
> > > correct `black' and `white' colors on such displays.
> > >
> > > E.g. on amifb (which supports all bits_per_pixel from 1 through 8) the logo
> > > showed up in black-and-blue with bits_per_pixel == 3, cfr. the first two
> > > entries of {red,green,blue}8[] in fbcmap.c.
> > >
> >
> > Hmm, I see. I think only linux_logo_bw will be the only one affected,
> > since linux_logo_16 happens to match the console palette and in
> > linux_logo, we either reset the palette and/or the cmap.
>
> Indeed.
>
> > Would expanding each bit to the full bit depth work? Ie for bpp=8 using
> > monochrome data, white is 0 and black is 0xff.
>
> For bpp=8 that won't work, since we have 16 console colors only :-)
>
Of course :-)
> But for bpp=[1-3] that's OK, cfr. fbcmap.c.
>
> BTW, perhaps it makes sense to just pass the appropriate `black' and `white'
> pixel values to the logo conversion routine? Preferably through a 2-element
> array, so we can index it with the logo data bit value instead of using
> tests/branches. Then we'd have:
>
Something like this?
static void fb_set_logo(struct fb_info *info, u8 *logo, int needs_logo)
{
int i, j;
u8 mask[2] = {0,0};
switch (needs_logo) {
case 4:
for (i = 0; i < (LOGO_W * LOGO_H)/2; i++) {
logo[i*2] = linux_logo16[i] >> 4;
logo[(i*2)+1] = linux_logo16[i] & 0xf;
}
break;
case 1:
case ~1:
mask[1] = (u8) ~(BIT_SHIFT(0xffff, info->var.bits_per_pixel));
for (i = 0; i < (LOGO_W * LOGO_H)/8; i++) {
u8 d = linux_logo_bw[i];
for (j = 0; j < 8; j++, d <<= 1)
logo[i*8+j] = mask[((d ^ needs_logo) >> 7) & 1];
}
break;
}
}
Tony
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: fb_imageblit()
From: Antonino Daplas @ 2003-01-08 16:25 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: James Simmons, Linux Frame Buffer Device Development
In-Reply-To: <Pine.GSO.4.21.0301081613510.21171-100000@vervain.sonytel.be>
On Wed, 2003-01-08 at 23:15, Geert Uytterhoeven wrote:
> > c. Read color information from pseudopalette if directcolor/truecolor.
>
> Hoever, pseudopalette has entries for the first 16 colors only!
> Hence you are limited to the 16 color for directcolor/truecolor modes.
That's why there's an fb_set_logo_directpalette(), for directcolor
visuals >= 24bpp, and fb_set_logo_truepalette(), for truecolor, in
fb_set_logo(). Basically, it temporarily replaces info->pseudo_palette
with one that has 256 entries to match linux_logo. Logo drawing, using
cfb_imageblit() has always worked for me in directcolor and truecolor
modes.
Tony
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: ipv6 stack seems to forget to send ACKs
From: Wichert Akkerman @ 2003-01-08 16:43 UTC (permalink / raw)
To: Maciej Soltysiak; +Cc: netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0301081718340.4542-100000@dns.toxicfilms.tv>
Previously Maciej Soltysiak wrote:
> I do not know how many tunnels are in my path, i know that hop distance to
> my tunnel is exactly 1 hop (ipv6 broker and ipv4 provider are the same)
My tunnel provider is 5 hops away. To my knowledge non of the ipv4 or
ipv6 hops in the path are congested and no traffic shaping is done.
> If there is immense traffic at one of the routers (total traffic on an
> interface) stream packets can be simply dropped if there are no queuing
> disciplines that would take eg. flow control into account.
I'll ask the ISPs involved to check if this might be happening, but I
highly doubt it.
> btw. what the hell is JunOs ?
Juniper OS, running on Juniper routers.
Wichert.
--
Wichert Akkerman <wichert@wiggy.net> http://www.wiggy.net/
A random hacker
^ permalink raw reply
* Re: [linux-lvm] problem
From: Daniel Wittenberg @ 2003-01-08 16:34 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <20030108223008.G28021@uk.sistina.com>
If all it needs is the dm-ioctl.h I can grab that. This was just
turning into a "needs this one more file...one more file" sorta thing,
so didn't want to spend all night chasing files.
Thanks,
Dan
On Wed, 2003-01-08 at 16:30, Alasdair G Kergon wrote:
> On Wed, Jan 08, 2003 at 04:24:47PM -0600, Daniel Wittenberg wrote:
> > I didn't see any pre-built binaries, so I started down the source path,
> If you don't have any kernel source lying around, yes, you'll have
> to fiddle to compile device-mapper. [It needs .h file from the
> kernel patch.]
>
> I'll do you a version of LVM2 that can be compiled without
> device-mapper.
>
> Alasdair
--
===========================
Daniel Wittenberg
Senior Unix Admin
University of Iowa - ITS
^ permalink raw reply
* Re: ipv6 stack seems to forget to send ACKs
From: Maciej Soltysiak @ 2003-01-08 16:39 UTC (permalink / raw)
To: Wichert Akkerman; +Cc: netdev, linux-kernel
In-Reply-To: <20030108150201.GA30490@wiggy.net>
> Previously Wichert Akkerman wrote:
> > traceroute to ipv6.lkml.org (2001:968:1::2) from
> > 3ffe:8280:10:1d0:290:27ff:fe2d:968c, 30 hops max, 16 byte packets
> > 1 thunder.wiggy.net (3ffe:8280:10:1d0:250:4ff:fe0b:dd79) 0.666 ms 0.22 ms 0.199 ms
> > 2 xs4all-29.ipv6.xs4all.nl (3ffe:8280:0:2001::58) 27.568 ms 28.012 ms 30.177 ms
> > 3 26.ge-0-2-0.xr1.pbw.xs4all.net (2001:888:0:3::1) 22.035 ms 19.528 ms 44.644 ms
> > 4 0.ge-0-3-0.xr1.sara.xs4all.net (2001:888:2:1::1) 19.519 ms 19.002 ms 21.974 ms
> > 5 fe-0-0-0.ams-core-01.network6.isp-services.nl (2001:7f8:1::a502:4875:1) 19.978 ms 30.278 ms 20.248 ms
> > 6 2001:968::2 (2001:968::2) 24.246 ms 24.083 ms 22.918 ms
> > 7 2001:968:1::2 (2001:968:1::2) 24.978 ms 23.866 ms 23.661 ms
> >
> > thunder.wiggy.net is my Linux router running 2.4.19-pre5-ac3-freeswan196
> > currently. The second hop is a normal sit tunnel and all the other
> > hops are native ipv6 using Cisco and Juniper routers as far as I know.
>
> Slight correction to that: xs4all-29.ipv6.xs4all.nl is a FreeBSD-4.5
> tunnel server. The toher xs4all.net hops are Junipers running JunOS 5.3
> or 5.5.
I had four contiguous listenings:
3 mins
10mins
19mins
13mins
When i increased the buffer in xmms i got better uninterrupted timings.
And survived data gaps better.
I seem to be getting better results than you, i think that it is not an
issue of ipv6 implementation but simply the case of time sensitive
traffic fighting with other Internet traffic over tunnels through ipv4
networks.
I do not know how many tunnels are in my path, i know that hop distance to
my tunnel is exactly 1 hop (ipv6 broker and ipv4 provider are the same)
If there is immense traffic at one of the routers (total traffic on an
interface) stream packets can be simply dropped if there are no queuing
disciplines that would take eg. flow control into account.
What do you think?
btw. what the hell is JunOs ?
Regards,
Maciej Soltysiak
^ 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.