RE: Cosmetic JFFS patch.
(cc's trimmed a little.) As someone who actually has created an embedded Linux distribution for a set top box, I can say that the boot output has never been a problem for me. I like verbose output, it's useful. Developers probably know that once you have the system booting nicely and you've quit messing with the kernel, you can put APPEND = "console=/dev/tty2 CONSOLE=/dev/tty2" in lilo.conf. With framebuffer support and a custom, full screen boot logo, the graphics appear immediately after the kernel starts, and no text ever appears on screen. After init gets going, you can continue to dump text output to tty2 while you display pretty pictures in the framebuffer or start X. So, I can't see verbose text output being a problem for anyone developing for embedded systems... that memory is all freed after boot anyway. So here's a real copyright / trademark / GPL question: Suppose some embedded Linux system developer wants to put their trademarked, copyrighted logo on the screen during the boot. So they compile it into the linux_logo.h image. It's now under the GPL, of course... what does that do to the legal status of the logo? Incidentally, the copyright and other messages have never bothered me. I figure if some company is going to do me the favor of sponsoring development of software I can use for free, I really don't mind being reminded of it. MP3.com definitely scores karma points with me for sponsoring Reiser, for instance. Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Cosmetic JFFS patch.
(cc's trimmed a little.) As someone who actually has created an embedded Linux distribution for a set top box, I can say that the boot output has never been a problem for me. I like verbose output, it's useful. Developers probably know that once you have the system booting nicely and you've quit messing with the kernel, you can put APPEND = console=/dev/tty2 CONSOLE=/dev/tty2 in lilo.conf. With framebuffer support and a custom, full screen boot logo, the graphics appear immediately after the kernel starts, and no text ever appears on screen. After init gets going, you can continue to dump text output to tty2 while you display pretty pictures in the framebuffer or start X. So, I can't see verbose text output being a problem for anyone developing for embedded systems... that memory is all freed after boot anyway. So here's a real copyright / trademark / GPL question: Suppose some embedded Linux system developer wants to put their trademarked, copyrighted logo on the screen during the boot. So they compile it into the linux_logo.h image. It's now under the GPL, of course... what does that do to the legal status of the logo? Incidentally, the copyright and other messages have never bothered me. I figure if some company is going to do me the favor of sponsoring development of software I can use for free, I really don't mind being reminded of it. MP3.com definitely scores karma points with me for sponsoring Reiser, for instance. Torrey Hoffman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
Adam J. Richter wrote: > Doug Ledford wrote: > >"Adam J. Richter" wrote: > > >> On the question of whether this is nothing more than > >> aggregation, ... [patent law definition of aggregation] ... Well, I'm just an interested bystander. But having read the recent lkml posts on this issue, it seems to me that the critical points are: >From the point of view of the kernel, the firmware code is just a big magic number that "turns on" the firmware. The kernel is not _linked_ _with_ the firmware code. The kernel doesn't even _exec_ the firmware. The firmware code can be used, unmodified, in other operating systems. The firmware code does not run in the same address space as the kernel. In principle, and maybe in practice, that firmware code might be running on a different processor, with different RAM, and a different instruction set. It's obviously not part of the kernel! Torrey Hoffman - [EMAIL PROTECTED] --- I find this corpse guilty of carrying a concealed weapon and I fine it $40. -- Judge Roy Bean, finding a pistol and $40 on a man he'd just shot. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
Adam J. Richter wrote: Doug Ledford wrote: Adam J. Richter wrote: On the question of whether this is nothing more than aggregation, ... [patent law definition of aggregation] ... Well, I'm just an interested bystander. But having read the recent lkml posts on this issue, it seems to me that the critical points are: From the point of view of the kernel, the firmware code is just a big magic number that turns on the firmware. The kernel is not _linked_ _with_ the firmware code. The kernel doesn't even _exec_ the firmware. The firmware code can be used, unmodified, in other operating systems. The firmware code does not run in the same address space as the kernel. In principle, and maybe in practice, that firmware code might be running on a different processor, with different RAM, and a different instruction set. It's obviously not part of the kernel! Torrey Hoffman - [EMAIL PROTECTED] --- I find this corpse guilty of carrying a concealed weapon and I fine it $40. -- Judge Roy Bean, finding a pistol and $40 on a man he'd just shot. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Unresolved symbol compiling a standalone module?
I'm compiling a standalone kernel module outside the kernel tree. The compile completes fine, but when I try to insmod it, I get: unresolved symbol printk_R1b7d4074 unresolved symbol __const_udelay_Reae3dfd6 This is very strange, because a quick grep of some of the regular, loaded modules, like /lib/modules/2.2.19/net/eepro100.o, shows that they contain those exact symbols! So why are they "unresolved" in mine? CONFIG_MODVERSIONS = 1, kernel is 2.2.19 + reiserfs, and I have checked my standalone module's makefile to ensure that it uses _exactly_ the same gcc options as the normal kernel modules. My /usr/include/linux directory is a symbolic link to /usr/src/linux/include, and /usr/src/linux is the kernel I'm running. What am I doing wrong? Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Unresolved symbol compiling a standalone module?
I'm compiling a standalone kernel module outside the kernel tree. The compile completes fine, but when I try to insmod it, I get: unresolved symbol printk_R1b7d4074 unresolved symbol __const_udelay_Reae3dfd6 This is very strange, because a quick grep of some of the regular, loaded modules, like /lib/modules/2.2.19/net/eepro100.o, shows that they contain those exact symbols! So why are they unresolved in mine? CONFIG_MODVERSIONS = 1, kernel is 2.2.19 + reiserfs, and I have checked my standalone module's makefile to ensure that it uses _exactly_ the same gcc options as the normal kernel modules. My /usr/include/linux directory is a symbolic link to /usr/src/linux/include, and /usr/src/linux is the kernel I'm running. What am I doing wrong? Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] automated remote install of Linux from WinNT4
Apologies for the off topic post. I have searched Google, Freshmeat and Sourceforge without success, and this is where the smart people are... I need to do an automated, remote installation of Linux on a large number of networked computers running Windows NT 4.0. I can place an executable on each of these computers and run it with Admin privileges. These computers are using an NTFS file system and have unpartitioned space available. So, I need a Windows NT program that can create a bootable Linux partition, and then reboot into Linux from that partition. Does anyone know of anything like that? If nothing like this exists, I will have to write it in the next month or two. My hypothetical plan is to (1) port a recent LILO or GRUB to Windows, and then (2) write a Windows NT program that creates a small FAT32 partition, formats it, mounts it, and copies in the kernel, modules, init, and a minimal set of essential files. It would then run the Windows NT port of LILO/GRUB to set up the MBR to boot Linux from the new partition. The minimal Linux install would bootstrap the rest of the Linux install over the network. Thanks for any advice or hints anyone can provide... Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] automated remote install of Linux from WinNT4
Apologies for the off topic post. I have searched Google, Freshmeat and Sourceforge without success, and this is where the smart people are... I need to do an automated, remote installation of Linux on a large number of networked computers running Windows NT 4.0. I can place an executable on each of these computers and run it with Admin privileges. These computers are using an NTFS file system and have unpartitioned space available. So, I need a Windows NT program that can create a bootable Linux partition, and then reboot into Linux from that partition. Does anyone know of anything like that? If nothing like this exists, I will have to write it in the next month or two. My hypothetical plan is to (1) port a recent LILO or GRUB to Windows, and then (2) write a Windows NT program that creates a small FAT32 partition, formats it, mounts it, and copies in the kernel, modules, init, and a minimal set of essential files. It would then run the Windows NT port of LILO/GRUB to set up the MBR to boot Linux from the new partition. The minimal Linux install would bootstrap the rest of the Linux install over the network. Thanks for any advice or hints anyone can provide... Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4 and 2GB swap partition limit
Kenneth Johansson wrote: > Jonathan Lundell wrote: > > > > (Does Linux swap out text, by the way, he asks ignorantly?) > > .text is just droped and read back from the actuall file it's > not put into the swap Is this always true, even for init? Can init be swapped out? In general, is there a safe way to replace executable files for programs that might be running while their on-disk images are replaced? Thanks for any hints... Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4 and 2GB swap partition limit
Kenneth Johansson wrote: Jonathan Lundell wrote: (Does Linux swap out text, by the way, he asks ignorantly?) .text is just droped and read back from the actuall file it's not put into the swap Is this always true, even for init? Can init be swapped out? In general, is there a safe way to replace executable files for programs that might be running while their on-disk images are replaced? Thanks for any hints... Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Single user linux
> think about personal devices. something like the nokia communicator. > a system security passwd is acceptable, but that's it. no those- > device-user would like to know about user account, file ownership, > etc. they just want to use it. If you are making a personal device, like an "appliance", there is no need to patch the kernel - at least not to remove the concept of users. Instead, change your startup scripts. In that situation, you will have a custom application that is automatically started at boot and runs with enough privileges to do whatever it needs. The user never sees a login prompt. If you want a Windows-95 style setup for Linux, you can do that too - but don't run as root! Just have the startup scripts auto-login as an unprivileged user. Kernel patches to do this are completely unnecessary, and a bad idea. Permissions are important to have on an appliance-like system, as they can be used to help prevent the end user from accessing the guts of the system which should be off limits for them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Single user linux
think about personal devices. something like the nokia communicator. a system security passwd is acceptable, but that's it. no those- device-user would like to know about user account, file ownership, etc. they just want to use it. If you are making a personal device, like an appliance, there is no need to patch the kernel - at least not to remove the concept of users. Instead, change your startup scripts. In that situation, you will have a custom application that is automatically started at boot and runs with enough privileges to do whatever it needs. The user never sees a login prompt. If you want a Windows-95 style setup for Linux, you can do that too - but don't run as root! Just have the startup scripts auto-login as an unprivileged user. Kernel patches to do this are completely unnecessary, and a bad idea. Permissions are important to have on an appliance-like system, as they can be used to help prevent the end user from accessing the guts of the system which should be off limits for them. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
An improved natsemi driver for 2.2
This version of the natsemi driver is being successfully used by us (Myrio Corporation) on hardware that has the 83815 chip on the motherboard, with the 2.2.17 kernel. It appears to work well with both multicast and unicast, with decent throughput. It requires the "pci-scan" module by Donald Becker at scyld.com. We would be very interested in any feedback on problems with 2.2.17 or 2.2.19, and our hope is that some experienced kernel developers will examine it and alert us of potential problems we haven't tripped over yet. Most of the code in this driver is by Donald Becker, of course. However, the driver from scyld.com could not receive packets on our hardware. We started from the modified version posted by Jocelyn Mayer. That one sort of worked for us but had problems. Our version backed out some of those changes, and has fixes for CRC calculation, reading the MAC address from the EEPROM, and other things. I (Torrey Hoffman) am not the developer of our version, although I did go through it and clean it up a little. I am the alleged "Linux expert" here, and if there are problems with the driver I am the person to contact. I'm cc'ing everyone on my "natsemi" address list, please trim followups. I do read the mailing list, but please cc me if responding. Thanks. Torrey Hoffman [EMAIL PROTECTED] [EMAIL PROTECTED] myrio-natsemi.c
An improved natsemi driver for 2.2
This version of the natsemi driver is being successfully used by us (Myrio Corporation) on hardware that has the 83815 chip on the motherboard, with the 2.2.17 kernel. It appears to work well with both multicast and unicast, with decent throughput. It requires the "pci-scan" module by Donald Becker at scyld.com. We would be very interested in any feedback on problems with 2.2.17 or 2.2.19, and our hope is that some experienced kernel developers will examine it and alert us of potential problems we haven't tripped over yet. Most of the code in this driver is by Donald Becker, of course. However, the driver from scyld.com could not receive packets on our hardware. We started from the modified version posted by Jocelyn Mayer. That one sort of worked for us but had problems. Our version backed out some of those changes, and has fixes for CRC calculation, reading the MAC address from the EEPROM, and other things. I (Torrey Hoffman) am not the developer of our version, although I did go through it and clean it up a little. I am the alleged "Linux expert" here, and if there are problems with the driver I am the person to contact. I'm cc'ing everyone on my "natsemi" address list, please trim followups. I do read the mailing list, but please cc me if responding. Thanks. Torrey Hoffman [EMAIL PROTECTED] [EMAIL PROTECTED] myrio-natsemi.c
RE: SiS 630
Tamas Nagy said: > Hello, > > I'm just wondering, whether somebody use this SiS 630 chip [...] I have a couple of the very small, highly-integrated ASUS CUSI-FX motherboards with the SiS 630 chipset. One is using a PIII-866 with 133 Mhz bus and 320MB RAM, and the other has a Celeron 300 and 66 Mhz bus with 128 MB RAM. (Motherboard description: SiS-630E, PIII/S370, SiS300AGP shared Memory 2M to 64M, Cmedia PCI Audio, 2P/ 1A/2D/2U, PC133/ VCM, SiS630E 10/100, w/ RJ45, ATA66, Flex ATX.) With 2.4.2-ac-?? and vanilla X 4.0.2, I have the onboard sound, VGA, IDE, and network working. The onboard video uses some of the system RAM, and the 2.4 kernels appears to detect that properly. Everything seems to work pretty well, I've compiled kernels, run setiathome, and copied hundreds of megs of data through the network, but I can't say I've _really_ stress tested them yet. I do have some problems with the CMedia sound: when playing MP3's, XMMS will run for a while and then just stop. That doesn't happen if I use an SBLive instead of the onboard audio. Haven't had time to track down the bug yet. For the onboard IDE, I'm using the generic driver, and use hdparm to turn on DMA and 32bit. That gives decent performance. Also, the motherboard has 5(!) USB sockets, and I haven't tried those yet, but there's no reason to believe they won't work too. Hope that helps. Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: SiS 630
Tamas Nagy said: Hello, I'm just wondering, whether somebody use this SiS 630 chip [...] I have a couple of the very small, highly-integrated ASUS CUSI-FX motherboards with the SiS 630 chipset. One is using a PIII-866 with 133 Mhz bus and 320MB RAM, and the other has a Celeron 300 and 66 Mhz bus with 128 MB RAM. (Motherboard description: SiS-630E, PIII/S370, SiS300AGP shared Memory 2M to 64M, Cmedia PCI Audio, 2P/ 1A/2D/2U, PC133/ VCM, SiS630E 10/100, w/ RJ45, ATA66, Flex ATX.) With 2.4.2-ac-?? and vanilla X 4.0.2, I have the onboard sound, VGA, IDE, and network working. The onboard video uses some of the system RAM, and the 2.4 kernels appears to detect that properly. Everything seems to work pretty well, I've compiled kernels, run setiathome, and copied hundreds of megs of data through the network, but I can't say I've _really_ stress tested them yet. I do have some problems with the CMedia sound: when playing MP3's, XMMS will run for a while and then just stop. That doesn't happen if I use an SBLive instead of the onboard audio. Haven't had time to track down the bug yet. For the onboard IDE, I'm using the generic driver, and use hdparm to turn on DMA and 32bit. That gives decent performance. Also, the motherboard has 5(!) USB sockets, and I haven't tried those yet, but there's no reason to believe they won't work too. Hope that helps. Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: a quest for a better scheduler
Timothy D. Witham wrote : [...] > I propose that we work on setting up a straight forward test harness > that allows developers to quickly test a kernel patch against > various performance yardsticks. [... (proposed large server testbeds) ...] I like this idea, but could the testbeds also include some resource-constrained "embedded" or appliance-style systems, and include performance yardsticks for latency and responsiveness? It would be unfortunate if work on a revised scheduler resulted in Linux being a monster web server on 4-way systems, but having lousy interactive performance on web pads, hand helds, and set top boxes. How about a 120Mhz Pentium with 32MB of RAM and a flash disk, a 200 Mhz PowerPC with 64 MB? Maybe a Transmeta web pad? For the process load, something that tests responsiveness and latency - how about a set of processes doing multicast network transfers, CPU-intensive MPEG video and audio encode / decode, and a test app that measures "user response", i.e. if X Windows was running, would the mouse pointer move smoothly or jerkily? The "better" scheduler for these applications would make sure that multicast packets were never dropped, the MPEG decode never dropped frames, and the "user interface" stayed responsive, etc. Also, I would not mind a bit if the kernel had tuning options, either in configuration or through /proc to adjust for these very different situations. Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: a quest for a better scheduler
Timothy D. Witham wrote : [...] I propose that we work on setting up a straight forward test harness that allows developers to quickly test a kernel patch against various performance yardsticks. [... (proposed large server testbeds) ...] I like this idea, but could the testbeds also include some resource-constrained "embedded" or appliance-style systems, and include performance yardsticks for latency and responsiveness? It would be unfortunate if work on a revised scheduler resulted in Linux being a monster web server on 4-way systems, but having lousy interactive performance on web pads, hand helds, and set top boxes. How about a 120Mhz Pentium with 32MB of RAM and a flash disk, a 200 Mhz PowerPC with 64 MB? Maybe a Transmeta web pad? For the process load, something that tests responsiveness and latency - how about a set of processes doing multicast network transfers, CPU-intensive MPEG video and audio encode / decode, and a test app that measures "user response", i.e. if X Windows was running, would the mouse pointer move smoothly or jerkily? The "better" scheduler for these applications would make sure that multicast packets were never dropped, the MPEG decode never dropped frames, and the "user interface" stayed responsive, etc. Also, I would not mind a bit if the kernel had tuning options, either in configuration or through /proc to adjust for these very different situations. Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel Summit info?
One of the reasons I read the kernel mailing list is that it's educational and fascinating to see the discussion between the kernel developers. This weekend (including today) many of the well known Linux developers are at the kernel summit meeting. I'm sure that having a face to face meeting like that is a great way to get a lot of work done quickly, and make some of the difficult decisions. I don't begrudge the developers for having a meeting like that. I don't even mind that it's invitation only. That was probably the only efficient way to organize it. However... for those of us who are curious, is there a web site somewhere with information about the goings-on? What would be really nice is web cams, or a RealAudio feed from the meetings. Is anything like that available? I'm really hoping that some of the people present at least post summaries about what the topics of discussion were, what options were looked at, and what decisions were made. Are any journalists there? Thanks. Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel Summit info?
One of the reasons I read the kernel mailing list is that it's educational and fascinating to see the discussion between the kernel developers. This weekend (including today) many of the well known Linux developers are at the kernel summit meeting. I'm sure that having a face to face meeting like that is a great way to get a lot of work done quickly, and make some of the difficult decisions. I don't begrudge the developers for having a meeting like that. I don't even mind that it's invitation only. That was probably the only efficient way to organize it. However... for those of us who are curious, is there a web site somewhere with information about the goings-on? What would be really nice is web cams, or a RealAudio feed from the meetings. Is anything like that available? I'm really hoping that some of the people present at least post summaries about what the topics of discussion were, what options were looked at, and what decisions were made. Are any journalists there? Thanks. Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: natsemi.c (Netgear FA311 card) probmlems??
Troy Benjegerdes wrote: [...] > Is anyone succesfully using a FA311 card (or anthing with a NatSemi > DP83815 chip?) We are working on the 2.2.x version of the driver. On our hardware, which has the DP83815 on the motherboard, Donald Becker's version was capable of sending packets but not receiving. I swapped some email with him on the subject about 6 weeks ago, sent him some debug output, but haven't heard anything recently. Meanwhile, we are doing some work on it ourselves. A "Jocelyn Mayer" posted a revised version of the driver which fixed some bugs but introduced others - at least on our hardware. Check the archives. Our version now sends and receives under 2.2.17, and is fixed to read and set the MAC address properly (!), but tends to have lousy performance. Large file transfers usually run at a pathetic 250 KB/s and often stall, but sometimes when the moon is in the right phase, run at a much more reasonable 7 MB/s. We are working on it... If anyone else out there has some improvements, I would love to hear about them. Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: natsemi.c (Netgear FA311 card) probmlems??
Troy Benjegerdes wrote: [...] Is anyone succesfully using a FA311 card (or anthing with a NatSemi DP83815 chip?) We are working on the 2.2.x version of the driver. On our hardware, which has the DP83815 on the motherboard, Donald Becker's version was capable of sending packets but not receiving. I swapped some email with him on the subject about 6 weeks ago, sent him some debug output, but haven't heard anything recently. Meanwhile, we are doing some work on it ourselves. A "Jocelyn Mayer" posted a revised version of the driver which fixed some bugs but introduced others - at least on our hardware. Check the archives. Our version now sends and receives under 2.2.17, and is fixed to read and set the MAC address properly (!), but tends to have lousy performance. Large file transfers usually run at a pathetic 250 KB/s and often stall, but sometimes when the moon is in the right phase, run at a much more reasonable 7 MB/s. We are working on it... If anyone else out there has some improvements, I would love to hear about them. Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: regression testing
Rik van Riel wrote: >This is definately a great idea. [...] >Note that some of these testing options are almost trivial to >set up [...] If an effort in this direction produced a "kernel-tester.tar.gz" package, I'm sure lots of people with spare hardware would install it, and then check it once a day for oops or crashes, and mail in the bug reports I have the spare hardware, I just don't have the time to constantly be downloading, compiling, and testing. I'm sure I'm not unique in that respect. An automated system would probably bring thousands of new machines on board for continuous testing, keeping it a community effort. Not that the testing work of IBM, SGI, Red Hat, et. al. is unappreciated, but a distributed, open, regression testing package sort of fits the Linux philosophy and model... Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: regression testing
Rik van Riel wrote: This is definately a great idea. [...] Note that some of these testing options are almost trivial to set up [...] If an effort in this direction produced a "kernel-tester.tar.gz" package, I'm sure lots of people with spare hardware would install it, and then check it once a day for oops or crashes, and mail in the bug reports I have the spare hardware, I just don't have the time to constantly be downloading, compiling, and testing. I'm sure I'm not unique in that respect. An automated system would probably bring thousands of new machines on board for continuous testing, keeping it a community effort. Not that the testing work of IBM, SGI, Red Hat, et. al. is unappreciated, but a distributed, open, regression testing package sort of fits the Linux philosophy and model... Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
on /etc/mtab vs. /proc/mounts (Was RE: Linux should better cope with power failure)
(Recipients trimmed, as this is a major change of topic...) [big cut] > Actually, I think /etc/mtab is not needed at all. This is already mostly correct, AFAIK. My embedded system uses "busybox" for mount and umount, /etc/mtab does not exist, and the root file system is readonly. But if I do "umount -a" it works. So the busybox umount is already reading /proc/mounts. The only oddity I see with using /proc/mounts is that it shows: /dev/root / ext2 rw 0 0 instead of /dev/hda1 / ext2 rw 0 0 but this doesn't seem to cause any problems... even though /dev/root does not exist (!) In fact, the "mount" man page on my Mandrake 7.2 system says: "It is possible to replace /etc/mtab by a symbolic link to /proc/mounts..." and then goes on to describe some of the issues and problems with doing so - loopback, and paths with spaces seem to be the significant ones. Hopefully those problems can and will be solved soon, and then we can get rid of /etc/mtab completely, and keep the root partition read only almost all the time. Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux should better cope with power failure
Otto Wyss wrote: > situation was switching power off and on after a few minutes of > inactivity. From the impression I got during the following startup, I You aren't giving a lot of detail here. I assume your startup scripts run fsck, and you saw a lot of errors. Were any of them uncorrectable? > assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power > failiure or manually switching it off. Not even if there wasn't any > activity going on. That is correct. Pulling the plug on non-journaled filesystems is a bad idea. > Shouldn't a good system allways try to be on the save side? Yes. Some of this is your responsibility. You have several options: 1. Get a UPS. That would not have helped your particular problem, but it's a good idea if you care about data integrity. 2. Use a journaling file system. These are much more tolerant of abuse. Reiserfs seems to work for me on embedded systems I am building where the user can (and does) remove the power any time. 3. Use RAID. Hard drives are very cheap and software raid is very easy to set up. > There is currently much work done in > getting high performance during high activity but it seems there is no > work done at all in getting a save system during low/no activity. Actually, a lot of work _is_ being done on journaling file systems which help solve this problem. Current journaling file systems are metadata only, but Tux2 (if I understand it) will journal everything. > How could this be accomplished: > 1. Flush any dirty cache pages as soon as possible. There may > not be any > dirty cache after a certain amount of idle time. This can be done from user space. The simple approach would be to set up a cron job to sync and flush buffers every "n" seconds. A smarter approach would examine the load average, and not sync if the load was high. This does not need to be in the kernel. > 2. Keep open files in a state where it doesn't matter if they where > improperly closed (if possible). This is mostly a user space problem as well. It has been solved for editors which automatically save files every "n" minutes. I don't know if it can be solved from kernel space - if applications leave files in an inconsistent state, how can the kernel possibly do anything about it? > 3. Swap may not contain anything which can't be discarded. Otherwise > swap has to be treated as ordinary disk space. I'm not an expert, but I don't think this is relevant? > Don't we tell children never go close to any abyss or doesn't have > alpinist a saying "never go to the limits"? So why is this simple rule > always broken with computers? So were you breaking this rule? Were you using a journaling file system, or RAID, or a UPS? Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux should better cope with power failure
Otto Wyss wrote: situation was switching power off and on after a few minutes of inactivity. From the impression I got during the following startup, I You aren't giving a lot of detail here. I assume your startup scripts run fsck, and you saw a lot of errors. Were any of them uncorrectable? assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power failiure or manually switching it off. Not even if there wasn't any activity going on. That is correct. Pulling the plug on non-journaled filesystems is a bad idea. Shouldn't a good system allways try to be on the save side? Yes. Some of this is your responsibility. You have several options: 1. Get a UPS. That would not have helped your particular problem, but it's a good idea if you care about data integrity. 2. Use a journaling file system. These are much more tolerant of abuse. Reiserfs seems to work for me on embedded systems I am building where the user can (and does) remove the power any time. 3. Use RAID. Hard drives are very cheap and software raid is very easy to set up. There is currently much work done in getting high performance during high activity but it seems there is no work done at all in getting a save system during low/no activity. Actually, a lot of work _is_ being done on journaling file systems which help solve this problem. Current journaling file systems are metadata only, but Tux2 (if I understand it) will journal everything. How could this be accomplished: 1. Flush any dirty cache pages as soon as possible. There may not be any dirty cache after a certain amount of idle time. This can be done from user space. The simple approach would be to set up a cron job to sync and flush buffers every "n" seconds. A smarter approach would examine the load average, and not sync if the load was high. This does not need to be in the kernel. 2. Keep open files in a state where it doesn't matter if they where improperly closed (if possible). This is mostly a user space problem as well. It has been solved for editors which automatically save files every "n" minutes. I don't know if it can be solved from kernel space - if applications leave files in an inconsistent state, how can the kernel possibly do anything about it? 3. Swap may not contain anything which can't be discarded. Otherwise swap has to be treated as ordinary disk space. I'm not an expert, but I don't think this is relevant? Don't we tell children never go close to any abyss or doesn't have alpinist a saying "never go to the limits"? So why is this simple rule always broken with computers? So were you breaking this rule? Were you using a journaling file system, or RAID, or a UPS? Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
on /etc/mtab vs. /proc/mounts (Was RE: Linux should better cope with power failure)
(Recipients trimmed, as this is a major change of topic...) [big cut] Actually, I think /etc/mtab is not needed at all. This is already mostly correct, AFAIK. My embedded system uses "busybox" for mount and umount, /etc/mtab does not exist, and the root file system is readonly. But if I do "umount -a" it works. So the busybox umount is already reading /proc/mounts. The only oddity I see with using /proc/mounts is that it shows: /dev/root / ext2 rw 0 0 instead of /dev/hda1 / ext2 rw 0 0 but this doesn't seem to cause any problems... even though /dev/root does not exist (!) In fact, the "mount" man page on my Mandrake 7.2 system says: "It is possible to replace /etc/mtab by a symbolic link to /proc/mounts..." and then goes on to describe some of the issues and problems with doing so - loopback, and paths with spaces seem to be the significant ones. Hopefully those problems can and will be solved soon, and then we can get rid of /etc/mtab completely, and keep the root partition read only almost all the time. Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Is swap == 2 * RAM a permanent thing?
IIRC, when this discussion of swap size first came up, the general conclusion was NOT that you should have swap = 2 * RAM, but that you should have swap(2.4.x) = 2 * swap(2.2.x), that is, twice as much swap as you did under 2.2.x. So if you never swapped at all under 2.2.x, you should not need any swap space in 2.4.x either. Is this correct? Also, what would be the consequences of not having "enough" swap? Just OOM faster? Or more serious than that? I have 512MB of RAM and rarely swap, so normally have just a 256MB swap partition. Is this bad? It seems to work fine... Thanks! Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Is swap == 2 * RAM a permanent thing?
IIRC, when this discussion of swap size first came up, the general conclusion was NOT that you should have swap = 2 * RAM, but that you should have swap(2.4.x) = 2 * swap(2.2.x), that is, twice as much swap as you did under 2.2.x. So if you never swapped at all under 2.2.x, you should not need any swap space in 2.4.x either. Is this correct? Also, what would be the consequences of not having "enough" swap? Just OOM faster? Or more serious than that? I have 512MB of RAM and rarely swap, so normally have just a 256MB swap partition. Is this bad? It seems to work fine... Thanks! Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux stifles innovation...
Dennis wrote: >At 07:01 PM 02/16/2001, Alan Olsen wrote: >>On Fri, 16 Feb 2001, Dennis wrote: >> >> > There is much truth to the concept, although Microsoft should not be ones >> > to comment on it as such. >> >>What truth? I have seen more "innovation" in the Open Source movement >>than I ever have in my 18+ years of being a professional programmer. >You are confusing "progress" with "innovation". If there is only 1 choice, >thats not innovation. Expanding on a bad idea, or even a good one, is not >innovation. > >Designing something differently to make it better is innovation. I suppose >you could argue that redesigning linux every few years is innovation, but >unfortunately its the same cast of characters doing it, so its not very >innovative. Reality check: 1. The Open Source / Free Software communities have produced more innovative software in the last 4 years than Microsoft has in the same time, despite Microsoft's _vast_ advantages in money, manpower, and hardware manufacturer relationships. 2. Where Microsoft is "innovating", those changes are usually intended to lock the customer in to Microsoft's products, and are not in the best interests of their own customers. 3. Far from Open Source being a threat to innovation, it is actually Microsoft that stifles innovation. Also, Free software helps the developers who use it to do innovative things, while Microsoft has endless restrictions. What has Microsoft done since 1996? Good and bad? What has Free Software done in the same time? Most of Microsoft's best ideas were more than 5 years ago, and since then they've mostly been integrating and marketing. They have done a few interesting things, but not nearly as much as they could have. Some things to consider, in no particular order: - Innovative new hardware devices are more likely to be based on Linux than any Microsoft OS. For example, the TiVO, the coolest improvement to television since the VCR. - ECN, IPv6, other RFC-standard improvements standard protocols - File systems: cramfs, reiserfs, Tux2, ext3, etc. - MS' new C# language. Java. Kaffe. Perl. Ruby. Python. - Cross platform support from System 390 to iPaq - Ogg Vorbis - Beowulf vs. that pathetic Microsoft beowulf-wanna-be. - Microsoft's "innovative" extensions to Kerebos. - Software for building community web sites, like Slashdot, Freshmeat, SourceForge, etc. - Mozilla - Integrating Internet Explorer into Windows. - RTLinux (does Microsoft have a hard real-time OS? Why not?) - Embedded Linux vs. Windows CE - Gnome and KDE user interfaces - works in progress, but lots of innovation there. - Gimp. Apache. - PHP, ModPerl, etc. vs ASP. - Jabber XML messaging platform - Handwriting recognition. MS has an edge here. - Scanner software APIs: TWAIN vs. SANE. - Direct3D vs OpenGL - XML-based, open file formats vs. proprietary file formats - Windows Update vs. apt-get, rpmfind, etc. - OpenSSH vs. ummm... BackOrfice? - IP over Firewire and other crazy, cool ideas - OpenBSD and line-by-line code audits. - .NET - Innovative new ways to spread viral documents and mail - In-kernel web server/accelerator, fastest in the world Don't forget Microsoft's latest innovation: integrating copy protection for music into the upcoming Windows XP OS, preventing people from fully controlling their own computer hardware. Feh. On the other hand, they make excellent mice. The mouse wheel and the new optical mice are truly innovative and Microsoft should be commended for them. Yours truly, Torrey Hoffman - a relative nobody in the world of free software. But I use it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux stifles innovation...
Henning P. Schmiedehausen wrote: > ... If you > write for Windows, you have an ugly and complicated API with lots of > bugs Yes, that is true. > , but the API itself is stable since six (!) years. You can write > programs that run on 95/98/ME/NT/2000 unchanged. That is not always true, as I learned by painful, repeated experience. My previous job, and some contract work I have done, involved writing software for Windows. My WORST problems were incompatibilities between Windows NT and Windows 95. The APIs do NOT, I repeat NOT! NOT! NOT! work the same on the various Windows flavors, as soon as you start doing non-trivial applications. Three times at least, portability problems from NT to Win95 cost me sleepless nights. Debugging stuff like that is hell when you don't have the source. And when things break on Win95 where they ran on NT, what do you do, run a debugger on Win95, where a crash can (and will) bring down the whole system? Ugh, the horror. Linux is not perfect yet, and there may be incompatibilities between library versions. But with the source, I have always been able to debug and fix the problems I've run into with much less pain than I ever had on Windows. I'm never going back. Yours, Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux stifles innovation...
Henning P. Schmiedehausen wrote: ... If you write for Windows, you have an ugly and complicated API with lots of bugs Yes, that is true. , but the API itself is stable since six (!) years. You can write programs that run on 95/98/ME/NT/2000 unchanged. That is not always true, as I learned by painful, repeated experience. My previous job, and some contract work I have done, involved writing software for Windows. My WORST problems were incompatibilities between Windows NT and Windows 95. The APIs do NOT, I repeat NOT! NOT! NOT! work the same on the various Windows flavors, as soon as you start doing non-trivial applications. Three times at least, portability problems from NT to Win95 cost me sleepless nights. Debugging stuff like that is hell when you don't have the source. And when things break on Win95 where they ran on NT, what do you do, run a debugger on Win95, where a crash can (and will) bring down the whole system? Ugh, the horror. Linux is not perfect yet, and there may be incompatibilities between library versions. But with the source, I have always been able to debug and fix the problems I've run into with much less pain than I ever had on Windows. I'm never going back. Yours, Torrey Hoffman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux stifles innovation...
Dennis wrote: At 07:01 PM 02/16/2001, Alan Olsen wrote: On Fri, 16 Feb 2001, Dennis wrote: There is much truth to the concept, although Microsoft should not be ones to comment on it as such. What truth? I have seen more "innovation" in the Open Source movement than I ever have in my 18+ years of being a professional programmer. You are confusing "progress" with "innovation". If there is only 1 choice, thats not innovation. Expanding on a bad idea, or even a good one, is not innovation. Designing something differently to make it better is innovation. I suppose you could argue that redesigning linux every few years is innovation, but unfortunately its the same cast of characters doing it, so its not very innovative. Reality check: 1. The Open Source / Free Software communities have produced more innovative software in the last 4 years than Microsoft has in the same time, despite Microsoft's _vast_ advantages in money, manpower, and hardware manufacturer relationships. 2. Where Microsoft is "innovating", those changes are usually intended to lock the customer in to Microsoft's products, and are not in the best interests of their own customers. 3. Far from Open Source being a threat to innovation, it is actually Microsoft that stifles innovation. Also, Free software helps the developers who use it to do innovative things, while Microsoft has endless restrictions. What has Microsoft done since 1996? Good and bad? What has Free Software done in the same time? Most of Microsoft's best ideas were more than 5 years ago, and since then they've mostly been integrating and marketing. They have done a few interesting things, but not nearly as much as they could have. Some things to consider, in no particular order: - Innovative new hardware devices are more likely to be based on Linux than any Microsoft OS. For example, the TiVO, the coolest improvement to television since the VCR. - ECN, IPv6, other RFC-standard improvements standard protocols - File systems: cramfs, reiserfs, Tux2, ext3, etc. - MS' new C# language. Java. Kaffe. Perl. Ruby. Python. - Cross platform support from System 390 to iPaq - Ogg Vorbis - Beowulf vs. that pathetic Microsoft beowulf-wanna-be. - Microsoft's "innovative" extensions to Kerebos. - Software for building community web sites, like Slashdot, Freshmeat, SourceForge, etc. - Mozilla - Integrating Internet Explorer into Windows. - RTLinux (does Microsoft have a hard real-time OS? Why not?) - Embedded Linux vs. Windows CE - Gnome and KDE user interfaces - works in progress, but lots of innovation there. - Gimp. Apache. - PHP, ModPerl, etc. vs ASP. - Jabber XML messaging platform - Handwriting recognition. MS has an edge here. - Scanner software APIs: TWAIN vs. SANE. - Direct3D vs OpenGL - XML-based, open file formats vs. proprietary file formats - Windows Update vs. apt-get, rpmfind, etc. - OpenSSH vs. ummm... BackOrfice? - IP over Firewire and other crazy, cool ideas - OpenBSD and line-by-line code audits. - .NET - Innovative new ways to spread viral documents and mail - In-kernel web server/accelerator, fastest in the world Don't forget Microsoft's latest innovation: integrating copy protection for music into the upcoming Windows XP OS, preventing people from fully controlling their own computer hardware. Feh. On the other hand, they make excellent mice. The mouse wheel and the new optical mice are truly innovative and Microsoft should be commended for them. Yours truly, Torrey Hoffman - a relative nobody in the world of free software. But I use it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: linux-logo.h
Ryan Hairyes ([EMAIL PROTECTED]) said: >Could anyone tell me about linux_logo.h. I want to put my >own picture in there. What format is the picture written in? >Any any idea on how I could change it? Also, could the >picture be any bigger than 80x80, I would like for it to take >up the whole screen. Probably the best thing for you do is to check out the FreeLords LPP patch, at http://lpp.freelords.org. Some people consider that one overkill, however... If you want to do it yourself, then the easiest way to put your own picture into linux_logo.h is to get the GIMP plugin called "glogo". I found a copy by searching on some GIMP plugin index web pages. The linux_logo.h just stores the images (and the palettes) as big arrays of hex numbers. In the GIMP, you create three versions of your image - one with 214 colors, one with 16, and one in black and white. Then you run the glogo plugin and feed it your three images. It will output a file that you can name linux_logo.h and copy into the include/linux directory. However, if I recall correctly, the 80x80 restriction is coded into the kernel in at least two places, as well as the glogo plug in. (yuck!) So, what you really want is a patch I made for the 2.2.17 and later series which makes it easy to put bigger logos in, and also center them on the screen and other little things. My patch is not that exciting though, anyone with some C programming skill could do the same thing in a couple of hours, no previous kernel experience necessary. I have a hacked up version of glogo to go along with my kernel patch, which moves some of the LOGO_W and LOGO_H #defines around to tidy it up a bit. It also makes it easy to have completely different images for the 16 color and B images - you could leave the 80x80 penguin in for those if you want, while putting in a nice big 214 color logo. If you want my patch and glogo hack, just email me. There are other, similar patches out there. I read about one last fall that actually had the ability to convert a png into the linux_logo.h during a kernel build. Also note that putting in a huge logo will make your kernel bzImage or zImage noticeably larger. This is not likely to be a problem if you use modules for most things. Best wishes, Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
RE: linux-logo.h
Ryan Hairyes ([EMAIL PROTECTED]) said: Could anyone tell me about linux_logo.h. I want to put my own picture in there. What format is the picture written in? Any any idea on how I could change it? Also, could the picture be any bigger than 80x80, I would like for it to take up the whole screen. Probably the best thing for you do is to check out the FreeLords LPP patch, at http://lpp.freelords.org. Some people consider that one overkill, however... If you want to do it yourself, then the easiest way to put your own picture into linux_logo.h is to get the GIMP plugin called "glogo". I found a copy by searching on some GIMP plugin index web pages. The linux_logo.h just stores the images (and the palettes) as big arrays of hex numbers. In the GIMP, you create three versions of your image - one with 214 colors, one with 16, and one in black and white. Then you run the glogo plugin and feed it your three images. It will output a file that you can name linux_logo.h and copy into the include/linux directory. However, if I recall correctly, the 80x80 restriction is coded into the kernel in at least two places, as well as the glogo plug in. (yuck!) So, what you really want is a patch I made for the 2.2.17 and later series which makes it easy to put bigger logos in, and also center them on the screen and other little things. My patch is not that exciting though, anyone with some C programming skill could do the same thing in a couple of hours, no previous kernel experience necessary. I have a hacked up version of glogo to go along with my kernel patch, which moves some of the LOGO_W and LOGO_H #defines around to tidy it up a bit. It also makes it easy to have completely different images for the 16 color and BW images - you could leave the 80x80 penguin in for those if you want, while putting in a nice big 214 color logo. If you want my patch and glogo hack, just email me. There are other, similar patches out there. I read about one last fall that actually had the ability to convert a png into the linux_logo.h during a kernel build. Also note that putting in a huge logo will make your kernel bzImage or zImage noticeably larger. This is not likely to be a problem if you use modules for most things. Best wishes, Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
RE: Knowing what options a kernel was compiled with
Should someone submit a patch to copy the .config to a standard location as part of "make install" or "make modules_install"? If included in the official sources, that good example would encourage the distribution maintainers do the same. Torrey Hoffman >-Original Message- >From: Keith Owens [mailto:[EMAIL PROTECTED]] >[...] >I know that some distributions ship .config but not all do. A long way >down on my TODO list is "submit a requirement to FHS that .config, >System.map and other kernel related text files must be shipped in >directory ". >[...] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Knowing what options a kernel was compiled with
Should someone submit a patch to copy the .config to a standard location as part of "make install" or "make modules_install"? If included in the official sources, that good example would encourage the distribution maintainers do the same. Torrey Hoffman -Original Message- From: Keith Owens [mailto:[EMAIL PROTECTED]] [...] I know that some distributions ship .config but not all do. A long way down on my TODO list is "submit a requirement to FHS that .config, System.map and other kernel related text files must be shipped in directory foo". [...] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Total loss with 2.4.0 (release) [off topic now...]
This is getting off topic, but it's good to spread the info around: Mike A. Harris (mailto:[EMAIL PROTECTED]) said: On Tue, 23 Jan 2001, Trever L. Adams wrote: >I know if you have a 8G drive or larger, and install NT4 on it it >will fry everything entirely unless you stand on your head and >read about 50 MS kb articles. Thankfully, I will _never_ have to >encounter this sort of thing again though. ;o) If you have to share a machine with a Microsoft OS, the best thing is to install the Microsoft OS first. That way it can set up the partition tables however it likes. Just leave enough hard drive space free. Then install Linux. This has several advantages - you can more easily set up Grub or Lilo to dual boot, and Linux can deal with whatever Microsoft's partition table flavor of the year is. The Microsoft OS is less likely to become confused and violently lash out using that approach :-) Another note: If dual-booting Windows 2000, upgrade to service pack 1 before installing Linux. I was able to blue-screen W2K before SP1 by starting their disk management tool on a disk with dozens of Linux partitions. And I agree - I am thankful that I will never have to deal with this again either. Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Total loss with 2.4.0 (release) [off topic now...]
This is getting off topic, but it's good to spread the info around: Mike A. Harris (mailto:[EMAIL PROTECTED]) said: On Tue, 23 Jan 2001, Trever L. Adams wrote: I know if you have a 8G drive or larger, and install NT4 on it it will fry everything entirely unless you stand on your head and read about 50 MS kb articles. Thankfully, I will _never_ have to encounter this sort of thing again though. ;o) If you have to share a machine with a Microsoft OS, the best thing is to install the Microsoft OS first. That way it can set up the partition tables however it likes. Just leave enough hard drive space free. Then install Linux. This has several advantages - you can more easily set up Grub or Lilo to dual boot, and Linux can deal with whatever Microsoft's partition table flavor of the year is. The Microsoft OS is less likely to become confused and violently lash out using that approach :-) Another note: If dual-booting Windows 2000, upgrade to service pack 1 before installing Linux. I was able to blue-screen W2K before SP1 by starting their disk management tool on a disk with dozens of Linux partitions. And I agree - I am thankful that I will never have to deal with this again either. Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Is there a Crystal 4299 sound driver?
Bill Nottingham said: >Torrey Hoffman ([EMAIL PROTECTED]) said: >> Does anyone know of a driver for the Crystal 4299 sound chip? > >It's not something there's one particular sound driver for (it's just >an ac97 codec chip, as you saw). Most likely you want to use something >like the i810_audio or via82cxxx_audio drivers. What does lspci say >on your machine? Here's an lspci -v dump. The machine is a set top box, pretty much a standard PC, but with hardware parts that are rarely seen in normal desktops. (The graphics card, ethernet card, and MPEG decoder chip all required non-standard Linux and X 4.0.2 drivers to work.) -- 00:00.0 Class 0600: 8086:7120 (rev 03) Flags: bus master, fast devsel, latency 0 00:1e.0 Class 0604: 8086:2418 (rev 02) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 3000-3fff Memory behind bridge: fc00-fdff 00:1f.0 Class 0601: 8086:2410 (rev 02) Flags: bus master, medium devsel, latency 0 00:1f.1 Class 0101: 8086:2411 (rev 02) (prog-if 80 [Master]) Subsystem: 8086:2411 Flags: bus master, medium devsel, latency 0 I/O ports at 1c00 00:1f.2 Class 0c03: 8086:2412 (rev 02) Subsystem: 8086:2412 Flags: bus master, medium devsel, latency 0, IRQ 9 I/O ports at 1400 00:1f.3 Class 0c05: 8086:2413 (rev 02) Subsystem: 8086:2413 Flags: medium devsel, IRQ 5 I/O ports at 1800 00:1f.5 Class 0401: 8086:2415 (rev 02) Subsystem: 110a:0051 Flags: bus master, medium devsel, latency 0, IRQ 5 I/O ports at 1000 I/O ports at 2000 01:06.0 Class 0300: 10ea:5000 (rev 03) Subsystem: 0280:7000 Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at fd00 (32-bit, non-prefetchable) I/O ports at 3000 01:07.0 Class 0200: 8086:1229 (rev 08) Subsystem: 8086:000c Flags: bus master, medium devsel, latency 66, IRQ 5 Memory at fc30 (32-bit, non-prefetchable) I/O ports at 3400 Memory at fc00 (32-bit, non-prefetchable) Capabilities: [dc] Power Management version 2 01:08.0 Class 0200: 100b:0020 Subsystem: 110a:005b Flags: bus master, medium devsel, latency 64, IRQ 9 I/O ports at 3800 Memory at fc301000 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 2 01:09.0 Class 0480: 1105:8400 (rev 01) Subsystem: 1105:00ff Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at fc10 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 1 01:0a.0 Class 0480: 1105:8400 (rev 01) Subsystem: 1105:00ff Flags: bus master, medium devsel, latency 64, IRQ 10 Memory at fc20 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 1 --- end ------- Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Is there a Crystal 4299 sound driver?
Bill Nottingham said: Torrey Hoffman ([EMAIL PROTECTED]) said: Does anyone know of a driver for the Crystal 4299 sound chip? It's not something there's one particular sound driver for (it's just an ac97 codec chip, as you saw). Most likely you want to use something like the i810_audio or via82cxxx_audio drivers. What does lspci say on your machine? Here's an lspci -v dump. The machine is a set top box, pretty much a standard PC, but with hardware parts that are rarely seen in normal desktops. (The graphics card, ethernet card, and MPEG decoder chip all required non-standard Linux and X 4.0.2 drivers to work.) -- 00:00.0 Class 0600: 8086:7120 (rev 03) Flags: bus master, fast devsel, latency 0 00:1e.0 Class 0604: 8086:2418 (rev 02) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 3000-3fff Memory behind bridge: fc00-fdff 00:1f.0 Class 0601: 8086:2410 (rev 02) Flags: bus master, medium devsel, latency 0 00:1f.1 Class 0101: 8086:2411 (rev 02) (prog-if 80 [Master]) Subsystem: 8086:2411 Flags: bus master, medium devsel, latency 0 I/O ports at 1c00 00:1f.2 Class 0c03: 8086:2412 (rev 02) Subsystem: 8086:2412 Flags: bus master, medium devsel, latency 0, IRQ 9 I/O ports at 1400 00:1f.3 Class 0c05: 8086:2413 (rev 02) Subsystem: 8086:2413 Flags: medium devsel, IRQ 5 I/O ports at 1800 00:1f.5 Class 0401: 8086:2415 (rev 02) Subsystem: 110a:0051 Flags: bus master, medium devsel, latency 0, IRQ 5 I/O ports at 1000 I/O ports at 2000 01:06.0 Class 0300: 10ea:5000 (rev 03) Subsystem: 0280:7000 Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at fd00 (32-bit, non-prefetchable) I/O ports at 3000 01:07.0 Class 0200: 8086:1229 (rev 08) Subsystem: 8086:000c Flags: bus master, medium devsel, latency 66, IRQ 5 Memory at fc30 (32-bit, non-prefetchable) I/O ports at 3400 Memory at fc00 (32-bit, non-prefetchable) Capabilities: [dc] Power Management version 2 01:08.0 Class 0200: 100b:0020 Subsystem: 110a:005b Flags: bus master, medium devsel, latency 64, IRQ 9 I/O ports at 3800 Memory at fc301000 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 2 01:09.0 Class 0480: 1105:8400 (rev 01) Subsystem: 1105:00ff Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at fc10 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 1 01:0a.0 Class 0480: 1105:8400 (rev 01) Subsystem: 1105:00ff Flags: bus master, medium devsel, latency 64, IRQ 10 Memory at fc20 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 1 --- end --- Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Is there a Crystal 4299 sound driver?
Does anyone know of a driver for the Crystal 4299 sound chip? I grepped through /drivers/sound in both 2.2.18 and 2.4.0. The only hints were that "ac97_codec.c" has two codec id's listed for it. >From old changelogs I see that Mulder Tjeerd was involved in adding those... perhaps he is writing a driver? Any hints would be appreciated. Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Is there a Crystal 4299 sound driver?
Does anyone know of a driver for the Crystal 4299 sound chip? I grepped through /drivers/sound in both 2.2.18 and 2.4.0. The only hints were that "ac97_codec.c" has two codec id's listed for it. From old changelogs I see that Mulder Tjeerd was involved in adding those... perhaps he is writing a driver? Any hints would be appreciated. Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 2.2.18 and Maxtor 96147H6 (61 GB)
I had exactly this problem with the Maxtor 61 GB drive on my Pentium based server. Theoretically a BIOS upgrade could fix it, but ASUS quit making BIOS upgrades for my motherboard two years ago. I solved the problem by getting a Promise Ultra 100 controller and putting the drive on that. Works perfectly under Linux Mandrake 2.2.17-mdk-21 - it shows up as /dev/hde. They are cheap controllers if you don't get the RAID version. Best wishes. Torrey Hoffman > From: Igmar Palsenberg [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 04, 2001 1:43 PM > Yeah.. I removed the clipping, and the machine won't boot. It halts after > PnP init. Any way to use full capacity with the clipping enabled ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
National Semiconductor DP83815 ethernet driver?
I am wondering about the current status of a driver for the NS83815 ethernet chip. >From searching Google, I know some sort of driver exists. In July, Adam J. Richter ([EMAIL PROTECTED]) posted a 2.2.16 driver he obtained from Dave Gotwisner at Wyse Technologies. And Tim Hockin mentioned that he was using an NSC driver, but had made some minor modifications. The only source I've seen is the one Mr. Richter posted. (http://web.gnu.walfield.org/mail-archive/linux-kernel/2000-July/4234.html). How well does this driver work? From Mr. Richter's email I gather that Alan Cox gave some feedback and suggested improvements. This makes me worried about using the "unimproved" version of the driver. If anyone has improved code for the 2.2.x series I would greatly appreciate it. 2.2.17 and 18 didn't include the driver. I also gather that Mr. Richter is (or was) concentrating on a port to the 2.4 series, how is that coming along? For what it's worth, the chip seems to have detailed documentation at http://www.national.com/pf/DP/DP83815.html. Thanks for any help. Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
National Semiconductor DP83815 ethernet driver?
I am wondering about the current status of a driver for the NS83815 ethernet chip. From searching Google, I know some sort of driver exists. In July, Adam J. Richter ([EMAIL PROTECTED]) posted a 2.2.16 driver he obtained from Dave Gotwisner at Wyse Technologies. And Tim Hockin mentioned that he was using an NSC driver, but had made some minor modifications. The only source I've seen is the one Mr. Richter posted. (http://web.gnu.walfield.org/mail-archive/linux-kernel/2000-July/4234.html). How well does this driver work? From Mr. Richter's email I gather that Alan Cox gave some feedback and suggested improvements. This makes me worried about using the "unimproved" version of the driver. If anyone has improved code for the 2.2.x series I would greatly appreciate it. 2.2.17 and 18 didn't include the driver. I also gather that Mr. Richter is (or was) concentrating on a port to the 2.4 series, how is that coming along? For what it's worth, the chip seems to have detailed documentation at http://www.national.com/pf/DP/DP83815.html. Thanks for any help. Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [patch] Make linux logo centered, add margins, etc. for 2.2.1 7
(This is an improved version of my earlier patch to linux-2.2.17. Thanks
are
due to Mohammad A. Haque and Even Jeffrey who gave me helpful tips on my
first
attempt. This version should correctly handle multiple CPUs.)
The patch adds an option to display a single, horizontally centered logo
with
optional vertical margins (LOGO_MARGIN), when framebuffer support is
compiled into the kernel, and an appropriate VGA= parameter is supplied.
This option is enabled by defining LOGO_CENTERED.
If LOGO_CENTERED is not defined, one logo will be shown for each CPU,
starting
from the left, (as the current code does) but still adding the margins above
and below.
Either way, the boot console displays in the remaining space. As before,
all
80x80 pixel restrictions on the logo size are removed, and the definitions
of
the logo size are moved to linux_logo.h so changing the logo only requires
changes to the single header file.
If you want to use this patch but keep the existing behavior, leave
LOGO_CENTERED
undefined and set all definitions of LOGO_MARGIN to 0.
Note: The _existing_ problem of what happens when (LOGO_W * smp_num_cpus) is
greater than the horizontal screen resolution has not been addressed.
For more information on this patch, see my first posting to this thread.
Please
let me know of bugs or problems - all I can really say is "it works for me",
and
it's pretty simple patch, so it should be ok.
Thanks.
Torrey Hoffman.
diff -u -r -x *.o -x *.flags -x *.depend -x *.config
linux-2.2.17/drivers/video/fbcon.c linux/drivers/video/fbcon.c
--- linux-2.2.17/drivers/video/fbcon.c Mon Sep 4 10:39:22 2000
+++ linux/drivers/video/fbcon.c Tue Oct 3 11:25:34 2000
@@ -31,6 +31,9 @@
*
* Random hacking by Martin Mares <[EMAIL PROTECTED]>
*
+ * Small changes for arbitrary size, optionally centered logos with
margins,
+ * cleanup so all logo size and positioning options are in linux_logo.h
+ * by Torrey Hoffman ([EMAIL PROTECTED]).
*
* The low level operations for the various display memory organizations
are
* now in separate source files.
@@ -107,8 +110,6 @@
# define DPRINTK(fmt, args...)
#endif
-#define LOGO_H 80
-#define LOGO_W 80
#define LOGO_LINE (LOGO_W/8)
struct display fb_display[MAX_NR_CONSOLES];
@@ -522,7 +523,7 @@
int cnt;
int step;
- logo_lines = (LOGO_H + fontheight(p) - 1) / fontheight(p);
+ logo_lines = (LOGO_H + LOGO_MARGIN + LOGO_MARGIN + fontheight(p) -
1) / fontheight(p);
q = (unsigned short *)(conp->vc_origin + conp->vc_size_row *
old_rows);
step = logo_lines * old_cols;
for (r = q - logo_lines * old_cols; r < q; r++)
@@ -2013,9 +2014,14 @@
if (p->fb_info->fbops->fb_rasterimg)
p->fb_info->fbops->fb_rasterimg(p->fb_info, 1);
+#if defined(LOGO_CENTERED)
+if (1) {
+ x = (p->var.xres - LOGO_W) / 2;
+#else
for (x = 0; x < smp_num_cpus * (LOGO_W + 8) &&
x < p->var.xres - (LOGO_W + 8); x += (LOGO_W + 8)) {
-
+#endif
+
#if defined(CONFIG_FBCON_CFB16) || defined(CONFIG_FBCON_CFB24) || \
defined(CONFIG_FBCON_CFB32) || defined(CONFIG_FB_SBUS)
if (p->visual == FB_VISUAL_DIRECTCOLOR) {
@@ -2032,7 +2038,7 @@
/* have at least 8 bits per color */
src = logo;
bdepth = depth/8;
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
+ for( y1 = LOGO_MARGIN; y1 < LOGO_H + LOGO_MARGIN; y1++ ) {
dst = fb + y1*line + x*bdepth;
for( x1 = 0; x1 < LOGO_W; x1++, src++ ) {
val = (*src << redshift) |
@@ -2058,7 +2064,7 @@
unsigned int pix;
src = linux_logo16;
bdepth = (depth+7)/8;
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
+ for( y1 = LOGO_MARGIN; y1 < LOGO_H + LOGO_MARGIN; y1++ ) {
dst = fb + y1*line + x*bdepth;
for( x1 = 0; x1 < LOGO_W/2; x1++, src++ ) {
pix = (*src >> 4) | 0x10; /* upper nibble */
@@ -2106,12 +2112,13 @@
blueshift = p->var.blue.offset - (8-p->var.blue.length);
src = logo;
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
+ for( y1 = LOGO_MARGIN; y1 < LOGO_H + LOGO_MARGIN; y1++ ) {
dst = fb + y1*line + x*bdepth;
for( x1 = 0; x1 < LOGO_W; x1++, src++ ) {
val = safe_shift((linux_logo_red[*src-32] & redmask),
redshift) |
safe_shift((linux_logo_green[*src-32] &
greenmask), greenshift) |
safe_shift((linux_logo_blue[*src-32] & bluemask),
blueshift);
+
if (bdepth == 4 && !((long)dst & 3)) {
/* Some cards require 32bit ac
RE: [patch] Make linux logo centered, add margins, etc. for 2.2.1 7
(This is an improved version of my earlier patch to linux-2.2.17. Thanks
are
due to Mohammad A. Haque and Even Jeffrey who gave me helpful tips on my
first
attempt. This version should correctly handle multiple CPUs.)
The patch adds an option to display a single, horizontally centered logo
with
optional vertical margins (LOGO_MARGIN), when framebuffer support is
compiled into the kernel, and an appropriate VGA= parameter is supplied.
This option is enabled by defining LOGO_CENTERED.
If LOGO_CENTERED is not defined, one logo will be shown for each CPU,
starting
from the left, (as the current code does) but still adding the margins above
and below.
Either way, the boot console displays in the remaining space. As before,
all
80x80 pixel restrictions on the logo size are removed, and the definitions
of
the logo size are moved to linux_logo.h so changing the logo only requires
changes to the single header file.
If you want to use this patch but keep the existing behavior, leave
LOGO_CENTERED
undefined and set all definitions of LOGO_MARGIN to 0.
Note: The _existing_ problem of what happens when (LOGO_W * smp_num_cpus) is
greater than the horizontal screen resolution has not been addressed.
For more information on this patch, see my first posting to this thread.
Please
let me know of bugs or problems - all I can really say is "it works for me",
and
it's pretty simple patch, so it should be ok.
Thanks.
Torrey Hoffman.
diff -u -r -x *.o -x *.flags -x *.depend -x *.config
linux-2.2.17/drivers/video/fbcon.c linux/drivers/video/fbcon.c
--- linux-2.2.17/drivers/video/fbcon.c Mon Sep 4 10:39:22 2000
+++ linux/drivers/video/fbcon.c Tue Oct 3 11:25:34 2000
@@ -31,6 +31,9 @@
*
* Random hacking by Martin Mares [EMAIL PROTECTED]
*
+ * Small changes for arbitrary size, optionally centered logos with
margins,
+ * cleanup so all logo size and positioning options are in linux_logo.h
+ * by Torrey Hoffman ([EMAIL PROTECTED]).
*
* The low level operations for the various display memory organizations
are
* now in separate source files.
@@ -107,8 +110,6 @@
# define DPRINTK(fmt, args...)
#endif
-#define LOGO_H 80
-#define LOGO_W 80
#define LOGO_LINE (LOGO_W/8)
struct display fb_display[MAX_NR_CONSOLES];
@@ -522,7 +523,7 @@
int cnt;
int step;
- logo_lines = (LOGO_H + fontheight(p) - 1) / fontheight(p);
+ logo_lines = (LOGO_H + LOGO_MARGIN + LOGO_MARGIN + fontheight(p) -
1) / fontheight(p);
q = (unsigned short *)(conp-vc_origin + conp-vc_size_row *
old_rows);
step = logo_lines * old_cols;
for (r = q - logo_lines * old_cols; r q; r++)
@@ -2013,9 +2014,14 @@
if (p-fb_info-fbops-fb_rasterimg)
p-fb_info-fbops-fb_rasterimg(p-fb_info, 1);
+#if defined(LOGO_CENTERED)
+if (1) {
+ x = (p-var.xres - LOGO_W) / 2;
+#else
for (x = 0; x smp_num_cpus * (LOGO_W + 8)
x p-var.xres - (LOGO_W + 8); x += (LOGO_W + 8)) {
-
+#endif
+
#if defined(CONFIG_FBCON_CFB16) || defined(CONFIG_FBCON_CFB24) || \
defined(CONFIG_FBCON_CFB32) || defined(CONFIG_FB_SBUS)
if (p-visual == FB_VISUAL_DIRECTCOLOR) {
@@ -2032,7 +2038,7 @@
/* have at least 8 bits per color */
src = logo;
bdepth = depth/8;
- for( y1 = 0; y1 LOGO_H; y1++ ) {
+ for( y1 = LOGO_MARGIN; y1 LOGO_H + LOGO_MARGIN; y1++ ) {
dst = fb + y1*line + x*bdepth;
for( x1 = 0; x1 LOGO_W; x1++, src++ ) {
val = (*src redshift) |
@@ -2058,7 +2064,7 @@
unsigned int pix;
src = linux_logo16;
bdepth = (depth+7)/8;
- for( y1 = 0; y1 LOGO_H; y1++ ) {
+ for( y1 = LOGO_MARGIN; y1 LOGO_H + LOGO_MARGIN; y1++ ) {
dst = fb + y1*line + x*bdepth;
for( x1 = 0; x1 LOGO_W/2; x1++, src++ ) {
pix = (*src 4) | 0x10; /* upper nibble */
@@ -2106,12 +2112,13 @@
blueshift = p-var.blue.offset - (8-p-var.blue.length);
src = logo;
- for( y1 = 0; y1 LOGO_H; y1++ ) {
+ for( y1 = LOGO_MARGIN; y1 LOGO_H + LOGO_MARGIN; y1++ ) {
dst = fb + y1*line + x*bdepth;
for( x1 = 0; x1 LOGO_W; x1++, src++ ) {
val = safe_shift((linux_logo_red[*src-32]redmask),
redshift) |
safe_shift((linux_logo_green[*src-32]
greenmask), greenshift) |
safe_shift((linux_logo_blue[*src-32] bluemask),
blueshift);
+
if (bdepth == 4 !((long)dst 3)) {
/* Some cards require 32bit access */
*(u32 *)dst = val;
@@ -2132,7 +2139,7 @@
#if defined(CONFIG_FBCON_CFB4)
if (depth == 4 p-type == FB_TYPE_PACKED_PIXELS) {
RE: [patch] Make linux logo centered, add margins, etc. for 2.2.17
Mohammad A. Haque provided enlightenment: >>Why does fbcon_show_logo() have a loop that looks at smp_num_cpus? > For every CPU you have you see one more Tux (blush) I should have figured that out for myself. You know, a different, or at least more comprehensive patch will be needed for machines with more than 8 processors, depending on screen resolution, since 8 Tux will overflow a 640 pixel wide screen. Of course, most of those machines won't be using framebuffer consoles at VGA resolutions... still... Yes, on SMP boxes the original design would be better. My patch is actually intended for embedded systems where you want a big, user-friendly logo on the screen instead of the console boot messages. Thanks for the tip. I'll change the patch. Actually, now that I understand that bit, I realize that a much better way to do it is to add x_start up there, for (x=x_start; x < smp_num_cpus * ..., rather than separately for each different version of the drawing loops. Torrey [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] Make linux logo centered, add margins, etc. for 2.2.17
This is a patch to linux-2.2.17.
As you all probably know, the current framebuffer driver (fbcon.c)
displays an 80x80 pixel penguin logo at the top left of the screen.
This patch modifies fbcon.c to display the linux logo centered
horizontally, with optional margins (LOGO_MARGIN) above and below.
The boot console displays in the remaining space.
It also cleans up the code a little to move the LOGO_W and LOGO_H
defines to the linux_logo.h header file, where they ought to be.
I have successfully used this code to display a large (472x320) logo
with the vesa framebuffer on i386 during boot. That only requires
replacing the include/linux/linux_header.h file.
This patch is currently untested on anything else, and I would be
interested in bug reports.
Note that using large logos can dramatically increase the size of
your zImage kernel. Also I'm not 100% confident the patch is correct,
as I'm not a kernel guru (yet). (Why does fbcon_show_logo() have a
loop that looks at smp_num_cpus?)
Anyway, if you find this interesting, you may also like to know that
I have updated the "glogo" gimp plugin, (which is GPL'ed and copyright
(C) 1998 Jens Ch. Restemeier <[EMAIL PROTECTED]>) to support:
- this modified linux_logo.h header format
- logos of variable size, instead of just 80x80 pixels
- gimp 1.1.26
If you want my version of glogo, just ask me. If this patch is
considered for inclusion in the official kernel, when I've recovered
from the shock I'll try to coordinate with with Jens Restemeier to
keep the "official" glogo up to date.
This is my first submission to the Linux Kernel mailing list. If
I've done anything incorrectly, please gently correct me so I can
get it right next time.
This patch was created in /usr/src with the command:
diff -u -r linux-2.2.17 linux
and can be applied in /usr/src/linux with the command
patch -p1 < ../linux_logo.patch
Thanks!
Torrey Hoffman
[EMAIL PROTECTED]
[EMAIL PROTECTED]
diff -u -r -x *.o -x *.flags -x *.depend linux-2.2.17/drivers/video/fbcon.c
linux/drivers/video/fbcon.c
--- linux-2.2.17/drivers/video/fbcon.c Mon Sep 4 10:39:22 2000
+++ linux/drivers/video/fbcon.c Mon Oct 2 08:50:46 2000
@@ -30,7 +30,9 @@
* Jakub Jelinek ([EMAIL PROTECTED])
*
* Random hacking by Martin Mares <[EMAIL PROTECTED]>
- *
+ *
+ * Small changes for arbitrary size, centered logos with margins
+ * by Torrey Hoffman ([EMAIL PROTECTED])
*
* The low level operations for the various display memory organizations
are
* now in separate source files.
@@ -107,10 +109,6 @@
# define DPRINTK(fmt, args...)
#endif
-#define LOGO_H 80
-#define LOGO_W 80
-#define LOGO_LINE (LOGO_W/8)
-
struct display fb_display[MAX_NR_CONSOLES];
static int logo_lines;
static int logo_shown = -1;
@@ -522,7 +520,7 @@
int cnt;
int step;
- logo_lines = (LOGO_H + fontheight(p) - 1) / fontheight(p);
+ logo_lines = (LOGO_H + LOGO_MARGIN + LOGO_MARGIN + fontheight(p) -
1) / fontheight(p);
q = (unsigned short *)(conp->vc_origin + conp->vc_size_row *
old_rows);
step = logo_lines * old_cols;
for (r = q - logo_lines * old_cols; r < q; r++)
@@ -1957,7 +1955,10 @@
/* Return if the frame buffer is not mapped */
if (!fb)
return 0;
-
+
+/* Center the linux logo horizontally */
+int x_start = (p->var.xres - LOGO_W) / 2;
+
/* Set colors if visual is PSEUDOCOLOR and we have enough colors, or
for
* DIRECTCOLOR */
if ((p->visual == FB_VISUAL_PSEUDOCOLOR && depth >= 4) ||
@@ -2015,7 +2016,7 @@
for (x = 0; x < smp_num_cpus * (LOGO_W + 8) &&
x < p->var.xres - (LOGO_W + 8); x += (LOGO_W + 8)) {
-
+
#if defined(CONFIG_FBCON_CFB16) || defined(CONFIG_FBCON_CFB24) || \
defined(CONFIG_FBCON_CFB32) || defined(CONFIG_FB_SBUS)
if (p->visual == FB_VISUAL_DIRECTCOLOR) {
@@ -2032,12 +2033,13 @@
/* have at least 8 bits per color */
src = logo;
bdepth = depth/8;
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
- dst = fb + y1*line + x*bdepth;
+ for( y1 = LOGO_MARGIN; y1 < LOGO_H + LOGO_MARGIN; y1++ ) {
+ dst = fb + y1*line + (x + x_start) * bdepth;
for( x1 = 0; x1 < LOGO_W; x1++, src++ ) {
val = (*src << redshift) |
(*src << greenshift) |
(*src << blueshift);
+
if (bdepth == 4 && !((long)dst & 3)) {
/* Some cards require 32bit access */
*(u32 *)dst = val;
@@ -2058,8 +2060,8 @@
unsigned int pix;
src = linux_logo16;
bdepth = (depth+7)/8;
- for( y1
[patch] Make linux logo centered, add margins, etc. for 2.2.17
This is a patch to linux-2.2.17.
As you all probably know, the current framebuffer driver (fbcon.c)
displays an 80x80 pixel penguin logo at the top left of the screen.
This patch modifies fbcon.c to display the linux logo centered
horizontally, with optional margins (LOGO_MARGIN) above and below.
The boot console displays in the remaining space.
It also cleans up the code a little to move the LOGO_W and LOGO_H
defines to the linux_logo.h header file, where they ought to be.
I have successfully used this code to display a large (472x320) logo
with the vesa framebuffer on i386 during boot. That only requires
replacing the include/linux/linux_header.h file.
This patch is currently untested on anything else, and I would be
interested in bug reports.
Note that using large logos can dramatically increase the size of
your zImage kernel. Also I'm not 100% confident the patch is correct,
as I'm not a kernel guru (yet). (Why does fbcon_show_logo() have a
loop that looks at smp_num_cpus?)
Anyway, if you find this interesting, you may also like to know that
I have updated the "glogo" gimp plugin, (which is GPL'ed and copyright
(C) 1998 Jens Ch. Restemeier [EMAIL PROTECTED]) to support:
- this modified linux_logo.h header format
- logos of variable size, instead of just 80x80 pixels
- gimp 1.1.26
If you want my version of glogo, just ask me. If this patch is
considered for inclusion in the official kernel, when I've recovered
from the shock I'll try to coordinate with with Jens Restemeier to
keep the "official" glogo up to date.
This is my first submission to the Linux Kernel mailing list. If
I've done anything incorrectly, please gently correct me so I can
get it right next time.
This patch was created in /usr/src with the command:
diff -u -r linux-2.2.17 linux
and can be applied in /usr/src/linux with the command
patch -p1 ../linux_logo.patch
Thanks!
Torrey Hoffman
[EMAIL PROTECTED]
[EMAIL PROTECTED]
diff -u -r -x *.o -x *.flags -x *.depend linux-2.2.17/drivers/video/fbcon.c
linux/drivers/video/fbcon.c
--- linux-2.2.17/drivers/video/fbcon.c Mon Sep 4 10:39:22 2000
+++ linux/drivers/video/fbcon.c Mon Oct 2 08:50:46 2000
@@ -30,7 +30,9 @@
* Jakub Jelinek ([EMAIL PROTECTED])
*
* Random hacking by Martin Mares [EMAIL PROTECTED]
- *
+ *
+ * Small changes for arbitrary size, centered logos with margins
+ * by Torrey Hoffman ([EMAIL PROTECTED])
*
* The low level operations for the various display memory organizations
are
* now in separate source files.
@@ -107,10 +109,6 @@
# define DPRINTK(fmt, args...)
#endif
-#define LOGO_H 80
-#define LOGO_W 80
-#define LOGO_LINE (LOGO_W/8)
-
struct display fb_display[MAX_NR_CONSOLES];
static int logo_lines;
static int logo_shown = -1;
@@ -522,7 +520,7 @@
int cnt;
int step;
- logo_lines = (LOGO_H + fontheight(p) - 1) / fontheight(p);
+ logo_lines = (LOGO_H + LOGO_MARGIN + LOGO_MARGIN + fontheight(p) -
1) / fontheight(p);
q = (unsigned short *)(conp-vc_origin + conp-vc_size_row *
old_rows);
step = logo_lines * old_cols;
for (r = q - logo_lines * old_cols; r q; r++)
@@ -1957,7 +1955,10 @@
/* Return if the frame buffer is not mapped */
if (!fb)
return 0;
-
+
+/* Center the linux logo horizontally */
+int x_start = (p-var.xres - LOGO_W) / 2;
+
/* Set colors if visual is PSEUDOCOLOR and we have enough colors, or
for
* DIRECTCOLOR */
if ((p-visual == FB_VISUAL_PSEUDOCOLOR depth = 4) ||
@@ -2015,7 +2016,7 @@
for (x = 0; x smp_num_cpus * (LOGO_W + 8)
x p-var.xres - (LOGO_W + 8); x += (LOGO_W + 8)) {
-
+
#if defined(CONFIG_FBCON_CFB16) || defined(CONFIG_FBCON_CFB24) || \
defined(CONFIG_FBCON_CFB32) || defined(CONFIG_FB_SBUS)
if (p-visual == FB_VISUAL_DIRECTCOLOR) {
@@ -2032,12 +2033,13 @@
/* have at least 8 bits per color */
src = logo;
bdepth = depth/8;
- for( y1 = 0; y1 LOGO_H; y1++ ) {
- dst = fb + y1*line + x*bdepth;
+ for( y1 = LOGO_MARGIN; y1 LOGO_H + LOGO_MARGIN; y1++ ) {
+ dst = fb + y1*line + (x + x_start) * bdepth;
for( x1 = 0; x1 LOGO_W; x1++, src++ ) {
val = (*src redshift) |
(*src greenshift) |
(*src blueshift);
+
if (bdepth == 4 !((long)dst 3)) {
/* Some cards require 32bit access */
*(u32 *)dst = val;
@@ -2058,8 +2060,8 @@
unsigned int pix;
src = linux_logo16;
bdepth = (depth+7)/8;
- for( y1 = 0; y1 LOGO_H; y1++ ) {
- dst = fb + y1*line + x*bdepth;
+ for( y1 = LOGO_MARGIN; y1 LOGO
RE: [patch] Make linux logo centered, add margins, etc. for 2.2.17
Mohammad A. Haque provided enlightenment: Why does fbcon_show_logo() have a loop that looks at smp_num_cpus? For every CPU you have you see one more Tux (blush) I should have figured that out for myself. You know, a different, or at least more comprehensive patch will be needed for machines with more than 8 processors, depending on screen resolution, since 8 Tux will overflow a 640 pixel wide screen. Of course, most of those machines won't be using framebuffer consoles at VGA resolutions... still... Yes, on SMP boxes the original design would be better. My patch is actually intended for embedded systems where you want a big, user-friendly logo on the screen instead of the console boot messages. Thanks for the tip. I'll change the patch. Actually, now that I understand that bit, I realize that a much better way to do it is to add x_start up there, for (x=x_start; x smp_num_cpus * ..., rather than separately for each different version of the drawing loops. Torrey [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
