Bug#415904: #415904: Reopened, updated patches to remove firmware blobs and to make driver available
Patches for Linux 2.6.22/2.6.23: ftp://flower.upol.cz/dts/lin0001_ti-usbserial/patches/fix-reconfig.patch ftp://flower.upol.cz/dts/lin0001_ti-usbserial/patches/v94_ti-usbserial.patch (Review from The Linux USB (and all other) Maintainer Forever is ass usual http://mid.gmane.org/[EMAIL PROTECTED], so my reply). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434752: Kernel hangs when I echo 0 /proc/sys/vm/vdso_enabled
* Date: Thu, 26 Jul 2007 15:21:49 +0200 Package: linux-2.6 Version: 2.6.22-2 Severity: normal [--] Summary: echo 0 /proc/sys/vm/vdso_enabled hangs my kernel. Since some months, I get unusable backtraces from gdb; I was pointed at an OpenSuse bug at: https://bugzilla.novell.com/show_bug.cgi?id=258433 which suggests disabling VDSO. My value of /proc/sys/vm/vdso_enabled is 2 before I try, and the system hangs shortly after I echo 0 in that tunable. http://mid.gmane.org/[EMAIL PROTECTED] Here you can find full Cc list of all heavy-lifters in the Linux kernel today (mis) doing that vDSO stuff all over last year. Try to make good bugreport send and see what will happened. The important issue I'd like to see fixed is this backtrace issue, but I'm reporting this crash as I think the kernel shouldn't crash and because I'm using this tunable to diagnose the backtrace issue. A debugger was mentiond here, if you can debug this/help, contact those guys: http://mid.gmane.org/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Critique of NO_HZ and thoughts about power savings (Re: 2.6.21)
On Mon, Jun 18, 2007 at 07:16:46AM +0200, Sven Luther wrote:
On Mon, Jun 18, 2007 at 12:06:38AM +0200, Oleg Verych wrote:
* From: Folkert van Heusden
* Date: Wed, 30 May 2007 17:18:40 +0200
* Organization: www.unixexpert.nl
Please consider upgrading to 2.6.21 or backporting the NO_HZ
functionality as it reduces powerusage of a processor and thus
saves the
environment.
{0}
since long enabled and is in sid.
Are you sure?
Yes. But only available for i386.
{1}
Ok, thanks.
Too much fallout (for .21 release) for useless feature even not for most
modern hardware, e.g. AMD64.
Mmm, i fail to see the relevantness of this with regard to the post
above, but ...
It's relevant to {0} and {1}, because of faith and probably fanaticism.
Thus, i tried to bring some facts and clear thinking (under new
subject). Hope they were constructive.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Killing tained reports before sending (Re: Bug#424881: linux-image-2.6.18-4-686-bigmem: kernel BUG at mm/slab.c:1572)
On Sun, May 20, 2007 at 03:09:43PM +0200, Bastian Blank wrote: On Thu, May 17, 2007 at 05:08:29PM +0200, Philipp Kolmann wrote: since my machine crashed for the third time with this slab.c bug on the console, I thought I post this now: The kernel is tainted. No support. What about that? Very simple way is one-two line to `reportbug` to check content of report against regex and print kind sorry-cancel message back (example is for shell ``source'' can be as follows): entry /Tained: P/ $PKGVER: The kernel was tained by a Proprietary module. Debian doesn't support this, contact module vendor, please. Such files can be in /usr/share/$PKG/doc/KNOWN-BUGS. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Critique of NO_HZ and thoughts about power savings (Re: 2.6.21)
* From: Folkert van Heusden * Date: Wed, 30 May 2007 17:18:40 +0200 * Organization: www.unixexpert.nl Please consider upgrading to 2.6.21 or backporting the NO_HZ functionality as it reduces powerusage of a processor and thus saves the environment. since long enabled and is in sid. Are you sure? Yes. But only available for i386. Ok, thanks. Too much fallout (for .21 release) for useless feature even not for most modern hardware, e.g. AMD64. Let me speak a little bit about one great misunderstanding of how things are actually work regarding electricity. I think you can realize, if i will point you, that DRAM, VGA, HDD are much more power hungry beasts. That for desktops. For servers as for computers with permanent Internet link NETCARD is another addition. Because even services-empty machine will listen for stupid misconfigured OS' broadcasts, port-scans, (in case of ssh) huge amount of cracking attempts. The major point about electricity is, that it cannot be accumulated in amounts comparable to consuming. With fact, that power plants cannot stop producing energy in the night time all this lead to one very sad conclusion: We are paying even for that electricity, that we do not actually consume. This is economical trick. where you were brain-washed about power-saving, while prices are still growing. Difference in day/night power might be compensated just for useless rotating of motors. But it seems better to useless light streets all night long. One big exception is day light savings. Because if you lower power consumption for relatively big amount of users for big period, power plants may low producing power. Not final truth, but still. Folkert van Heusden -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417333: FYI, may be have similar problem on another type of HW
From: Olivier Berger Newsgroups: gmane.linux.debian.devel.kernel Subject: Bug#417333: FYI, may be have similar problem on another type of HW Date: Mon, 02 Apr 2007 13:35:28 +0200 Hi. FYI, I entered a report (#417333) for a problem which show traces similar to that one... Well, i think #391955 may be closed, because it seems to be fixed in 2.6.18-stable by the patch from this report: http://permalink.gmane.org/gmane.linux.network/48625 (debug) http://permalink.gmane.org/gmane.linux.network/48703 (patch) I'm not sure though it's solved in latest kernel version. Please look at suggested in the link debugging tools, in case you will hit *your* bug again, because it has some traces of other fault: ,-*- | [...] dst_output | [...] ip_queue_xmit | [...] dst_output | [...] tcp_transmit_skb | [...] tcp_push_one | [...] tcp_sendmsg | [...] inet_sendmsg | [...] do_sock_write | [...] sock_writev | [...] do_wp_page | [...] __handle_mm_fault -- here | [...] autoremove_wake_function | [...] __next_cpu | [...] sock_writev | [...] do_readv_writev | [...] vfs_writev | [...] sys_writev | [...] sysenter_past_esp |Code: |EIP: [c024c735] tcp_tso_segment ... | 0Kernel panic - not syncing: Fatal exception in interrupt `-*- And that fault was preempted by the interrupt, thus we see a panic. So, this is my view on that. Hope it helps, also. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.20 [was Re: 2.6.21-rc5 ]
01-04-2007, maximilian attems: On Sat, 31 Mar 2007, Oleg Verych wrote: I'm running it nearly five days. I'm on amd64, without sysfs, did some dvd burning, playing music have strange random glitches (maybe some more NO_HZ problems). But i would suggest to wait next rc, it's going to be very soon. why waiting? it would have latest -git patch too. If with -git, that's fine. so next step would be to upload 2.6.20 into unstable. announcing upload for tuesday. please tell if you have some patches needing to go into. 2.6.20.5 is planned on the same day: | Responses should be made by Tuesday, April 3, 00:00:00 UTC. Anything | received after that time might be too late. | | thanks, | | greg k-h patch: kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.20.5-rc1.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.21-rc5
From: maximilian attems Subject: 2.6.21-rc5 Date: Sat, 31 Mar 2007 19:22:38 +0200 any voices against basing trunk on latest upstream? I'm running it nearly five days. I'm on amd64, without sysfs, did some dvd burning, playing music have strange random glitches (maybe some more NO_HZ problems). But i would suggest to wait next rc, it's going to be very soon. have an i386 working tree to commit. should 2.6.20 first be copied to sid? I don't how many testers were using it, but AFAIK there are some issues WRT defaults in MMCONFIG and MSI (new hardware mostly). -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sk98lin vs skge driver
From: Len Padilla Newsgroups: gmane.linux.debian.devel.kernel Subject: sk98lin vs skge driver Date: Fri, 30 Mar 2007 08:13:55 +0200 Please, see and comment Bug#416200: linux-image-2.6.18-4-686: Missing sk98lin module. Backport of the fiber support is impossible due to workqueue changes, thus old driver must be provided again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416210: linux-image-2.6.18-4-686 startup logs
On Wed, Mar 28, 2007 at 11:32:11AM +0200, Grzegorz Szyszlo wrote: On Wed, 28 Mar 2007, Oleg Verych wrote: OK. I don't have experience with such hardware. Try to select modules you need for basic boot, i.e. don't use MODULES=most in initramfs.conf, then manually load suspected modules, if you need them, of course. E.g. why piix* is needed on serverworks chipset? Help me, how should I exactly configure initramfs.conf and remake initrd ? Don't panic, sir. piix* is loaded later, after initrd. all partitions are mounted. I think, this module is loaded by hotplug or discover. Maybe this module try turn on DMA mode for IDE, because default DMA is disabled. But it completly hang up server. I read about it on the Internet. All people have problems with ServerWorks OSB4 and DMA enabled. man initramfs.conf Basicly what i do: * compose /etc/initramfs/modules * MODULES=list in initramfs.conf * chmod 000 /sbin/modprobe (finger for UglyDEV) * update-initramfs (some options like what to do and kernel version) Higher numer kernel resolve this problem, but I didn't try it. I can try any new knoppix or ubuntu cd live, they have more new kernels. Experimaental kernels are built and packaged for testing, see http://wiki.debian.org/DebianKernel I tryed to find option in BIOS that disable SMP, but this is classical SCSI BIOS, booted from configuration partition. There SMP options for Linux. I used this server on NetWare. It is no matter, when I selected in BIOS NetWare or NetWareSMP. Allways I coud use server as SMP. nosmp, noapic (see Documentation/kernel-parameters.txt) thanks. I'll try it, but after 18:00 GMT+2 (summer time), it'll be 16:00 UTC. Try experimental kernels also, please. I don't know why serverity is downgraded from critical to important. I set critical severity, because this kernel makes my system completly unusable, as descripted in report script. Maybe guys want to finally make a release. Very long dev. cycles isn't an open source's release early, release frequently. btw. chipset ServerWorks is used on HP Proliant Prosignia servers. Actually on the new servers this chipsets have revision OSB6. Well, if this is module vs. module config problem, then lets just solve this. Quality of drivers is question for upstream developers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automated kernel configuration and installation tool
From: Rafa? Jasinski Newsgroups: gmane.linux.debian.devel.kernel Subject: Automated kernel configuration and installation tool Date: Mon, 26 Mar 2007 18:56:55 +0200 Hallo. I'm a little lkml and debian-kernel *reader*, sometimes hacking on things i like, and replying on bugreports i think, i can help. Let me tell you something personal about your message, assuming, that YMMV. --=_Part_292724_20524001.1174928215487 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline First of all look at your message in a way kernel developers like, i mean rip off html junk and no multipart text-only body. This is my proposal for Summer of Code 2007 sent to Debian Org Project Title Synopsis The intention of the project is to design and implement a user-friendly tool used to configure a new kernel, [1] Purpose is? Users of the kernel configuring process are * kernel developers * kernel package developers * advanced users facing and capable tracing kernel bugs. I don't know about kfreebsd, but in linux (2.6) kernel configuration is something like select-all-as-modules by command 'make allmodconfig'. Some options are changed, of course, but it's mainly text-editor/pkg-config-file/'sed' problem, i.e kernel-package wrapper [kpw]. control its compilation process [2] I can't understand what do you mean here. Or it builds, or it doesn't. Most upstream kernel version must be build-able, or one must contact *upstream* obviously. and install it in the operating system. [3] Can't you be more specific about present problems, e.g by-hand method or [kpw]? The functionality and way of working with the intended program is going to resemble how APTITUDE works for applications. [4] AFAIK it's main purpose is to select, install and resolve needs of packages. Much like apt-get and apt-cache, but with some UI. Resolving of dependencies their main task. And they work OK for installation, but so far fail in removing/purging (there is some work toward this, though). So, what kind of dependencies you want to resolve in 'select-all' kernel? The kconfig and kbuild in linux-2.6 are *upstream* tools for custom configuring. Anyway, all you get is a text file, some key linux developers *are* editing manually. The motivation for the project is that contemporary Linux distributions contain either simple kernel configuration tools that do not give enough power to the users or, on the contrary, tools that are too difficult to use for newbies. The new piece of software is going to fill the gap and provide users with a user-friendly and, at the same time, powerful tool. [5] This are some more words for [1], [2] and [3], but they are nothing to clarify anything to me. As i said power-users are editing kernel config file by text or stream editor(check lkml, please). Newbies may try some *config options in *upstream* config tool. For newbies there's 'make defconfig' and 'make allyesconfig', what's the problem? Benefits to Debian Making Debian more usable and open to greater groups of users giving them more control over kernel administration, thus bringing it closer to perfection. [6] Key word is *administration*. It's new one here. What it means? Deliverables A program generating kernel configuration files based on user choices made in the user interface similar to APTITUDE, allowing to edit those files and then running and controlling kernel compilation and its installation in the system. Sound like kbuild, kconfig rewrite (in the linux kernel) [krewrite]. Project Details The software's functionality is going to be divided into a number of modules. One of them is going to be a user interface based on NCURSES with possibility to reimplement in other graphical environments. It is going to provide the user with choices of modules, suggest including proper kernel modules, Too much modules, thus disallow the user from making wrong choices. you will help users not to lost in them (: Nothing concrete WRT kernel. The program can load an existing configuration file and edit an already created configuration. [krewrite]? Upgrading selected kernel modules is going to be possible, including automatic module version conflict detection. The implementation will provide for extending the program with support for automatic download of proper kernel files from mirror servers. Aha modules. Here i can speculate, you are talking about external modules packaged in debs. Well, apt-cache shows some, that * outdated: fwatch (there's inotify) * useless: shfs-source (there's fuse+sshfs) * up-to-date with debs for most architectures: squashfs Thus, i think, external modules form the debian archive are not a problem. That were my personal opinion and comments after second and last read of your message. If you want make something useful, o would suggest to boil in that soup first: mailing lists, people, problems, maintaining,
Bug#416388: linux-source-2.6.18: Wodim hangs and system may freeze
From: John Talbut Newsgroups: gmane.linux.debian.devel.kernel Subject: Bug#416388: linux-source-2.6.18: Wodim hangs and system may freeze Date: Tue, 27 Mar 2007 15:41:42 +0100 Package: linux-source-2.6.18 Version: 2.6.18.dfsg.1-11 Severity: important This is similar to 265747, which was determined to be a kernel problem, but this is happening with a different kernel version, different package (wodim) and different drive. I insert a blank CD-R disk in the drive. I run: wodim dev=/dev/cdrw /home/john/debian-testing-i386-CD-1.iso If was broken for me since sarge to start with. As you may read on that reports, the problem is DMA. Did you try to switch off it on your opto-drive (hdparm -d0 /dev/cd-rw)? I always do this, before writing anything optical. If this helps, then kernel developers don't care much to debug and test it. Maybe because DMA is not important for this things. I doubt recording speed may be safely more than x16 (=2.4M/s), due to quality of storage. Thus, implementing things like DMA tests and using it in cdrecord is a bad idea, IMHO. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416388: linux-source-2.6.18: Wodim hangs and system may freeze
From: John Talbut Newsgroups: gmane.linux.debian.devel.kernel Subject: Bug#416388: linux-source-2.6.18: Wodim hangs and system may freeze Date: Tue, 27 Mar 2007 21:47:21 +0100 Thanks, Oleg, that has made a bit of difference. I did: hdparm -d0 /dev/cdrw in a root terminal and it responded with: /dev/cdrw: setting using_dma to 0 (off) HDIO_SET_DMA failed: Operation not permitted using_dma= 0 (off) Well, it can be wrong driver, who does not want to set DMA. Anyway, it seems, by (*) Leave as NEW status, unsolved in upstream (: http://bugzilla.kernel.org/show_bug.cgi?id=6745 I think, boot log, hdparm /dev/cdrw, hdparm -i /dev/cdrw would be good to have there. Also, please try latest experimental (http://wiki.debian.org/DebianKernel) or upstream (kernel.org linux2.6.21-rc5-git2) kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416210: linux-image-2.6.18-4-686 startup logs
On Tue, Mar 27, 2007 at 10:17:43PM +0200, Grzegorz Szyszlo wrote: [] I attach full boot console. First is 686 kernel. At the end boot is hanging, but I can ctrl+pgup/pgdown, and alt+ctrl+del reboot server immediately Next is 486 startup and last stopping messages. This works ok. I'm not exactly sure, ide cdrom driver cause problem. Sometimes system boot forward, after Uniform CD-ROM , but . load module piix*** and definitly hang up. System not respond for shift+pgup/pgdown and ctrl+alt+del . I can't reproduce it on serial console. OK. I don't have experience with such hardware. Try to select modules you need for basic boot, i.e. don't use MODULES=most in initramfs.conf, then manually load suspected modules, if you need them, of course. E.g. why piix* is needed on serverworks chipset? I tryed to find option in BIOS that disable SMP, but this is classical SCSI BIOS, booted from configuration partition. There SMP options for Linux. I used this server on NetWare. It is no matter, when I selected in BIOS NetWare or NetWareSMP. Allways I coud use server as SMP. nosmp, noapic (see Documentation/kernel-parameters.txt) What should I do? For test remove one processor? I'm sure, kernel has command to disable using apic, but I don't know what this command is. I'll try to find tommorow. Good luck. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#251023: upstream status of acpi-dsdt-initrd patch
From: dann frazier Newsgroups: gmane.linux.debian.devel.kernel Subject: Bug#251023: upstream status of acpi-dsdt-initrd patch Date: Sat, 24 Mar 2007 14:53:58 -0600 hey, I did a little research this morning to try to formulate an opinion - here's what I found:[...] A little bit outdated, i'd say. I also wonder if ACPI upstream would re-consider including this patch if DSDT-tainting was implemented?[...] From legal to technical sides of the question, fresh one is below: Newsgroups: gmane.linux.kernel From: Ben Collins Message-ID: [EMAIL PROTECTED] (if you're lazy to find and read whole thread, and using pretty-brain-damaging-webbrowser :) here are some key points: http://permalink.gmane.org/gmane.linux.kernel/471868 http://permalink.gmane.org/gmane.linux.kernel/472440 http://permalink.gmane.org/gmane.linux.kernel/471936 http://permalink.gmane.org/gmane.linux.kernel/471999 http://permalink.gmane.org/gmane.linux.kernel/472076 As for me, technical reasoning is mostly from the-kernel-developer: knowing, how request_firmware() ugly (from userspace _and_ in-kernel implementation points of view), suggestion to use vmlinuz objcopy (with ACPI_CUSTOM_DSDT) is rather the same as initrd patch (see last link). Only thing i agree, is multiple ugly hacks to have in mainstream, just to load yet another bin-blob in the right place in the right time. Thus, pushing BIOS updates is the only plausible way. Maybe those pro-Intel-ACPI dudes finaly got one ACPI-standard ACPI-BIOS-updating ACPI-interface, one can hack for all UNIX-like OSes. While Dell pushed it in Firmware Drivers in the kernel, Intel have its microcode updates there. *Sigh*! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416200: linux-image-2.6.18-4-686: Missing sk98lin module.
From: Andrew Nady Newsgroups: gmane.linux.debian.devel.kernel Subject: Bug#416200: linux-image-2.6.18-4-686: Missing sk98lin module. Date: Sun, 25 Mar 2007 17:41:49 -0400 Organization: Primary Support Systems Inc. [] As mentioned before. In the older kernel (2.6.18-3), most likely due to conflict with skge, I had to blacklist skge than rmmod sk98lin and insmod sk98lin on each reboot to get the eth2 working. As of 2.6.18-4 this is no longer functioning. skge here is too old, and maybe because of this ,-*- skge version 1.8+ -*- | Stephen Hemminger [Sun, 24 Sep 2006 04:25:28 + (21:25 -0700)] | | Add support for older fiber versions of the SysKonnect board. | These chipsets use an internal PHY so they require special handling. | The older sk98lin driver already supported these | | http://git.kernel.org/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commitdiff;h=64f6b64dfb8cdda21652f24a0fb0a68e2f0b0022 `-*- it will not handle this chip. Maybe 'sk98lin' should be returned back? Alternative is to backport changes to this in-rapid-development driver from the upstream. If core subsystems aren't changed much, i think, porting changes (not only bug fixes) to drivers isn't such a bad idea with today's hardware and development style of linux-2.6. But this can cause even more bugreports from (imho larger, than lkml) audience. Just my opinion. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416210: linux-image-2.6.18-4-686: Hangs at initrd boot state [i386] dual PentiumIII chipset ServerWorks OSB4
System: fresh pure install, all tasks from tasksel. On install state I hadn't any problems, but next boot cause any big problem for me: Kernel 2.6.18-4-486 works ok, but it has only ONE processor support and is slower. What kernel fully worked for you last time? Kernel 2.6.18-4-686 hangs at boot. I don't know how switch off SMP at boot for tests. In the BIOS (must be something APIC related) Finally system start up, but is very unstable. A lot of processes have zombie status. Can you grab dmesg and save it somewhere? Without boot log there's noone, who can help you, i guess. [] My needs: 1. I have two computers. Give me scheme for RS232 cable to save all startup log, and command for kernel to switch output to RS232. I can use minicom for getting messages.[] You need ordinary female-female(2-3, 3-2, 5-5) RS232 cable, or USB-to-RS232 cable. Serial console is activated by 'console=ttyS0' (default bautrate is 115200, i think, see more in Documentation/serial-console.txt). [] 2. I want temporarly switch off SMP on -686, try boot. 3. Maybe use 486 kernel version with SMP support[] Try some older kernels also. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415239: linux-image-2.6.18-4-amd64: general protection fault from powernow-k8
On Sun, Mar 25, 2007 at 10:49:30PM +1000, Hamish Moffatt wrote: [] I tried the 2.6.20 package from buildserver.net. It crashed similarly. Yes I had the nvidia driver loaded as usual :-| Full dmesg and without nvidia, please. I will try upstream 2.6.20 asap. Latest upstream is 2.6.21-rc5 (:. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415904: [Linux, ti_usb-serial] Removing (obsolete) firmware blobs, making driver usable (without udev scripts)
Package: linux-source-2.6.18 Version: 2.6.18.dfsg.1-11 Severity: important Tags: patch 1) In current form, i.e. without udev scripts, driver is unusable. 2) Two binary firmware blobs for different devices are staticaly included in the driver. While they are written to be GPL, Windows(R) driver package for such devices includes separate fimware files, thus providing updated ones and making blobs useless. Userspace helper was adopted to load that files. Filenames were taken from standard TI ez430 USB device driver package, where usb-serial is an interface. 3) To make driver usable usb_driver_set_configuration() crutch from 2.6.19 was taken, it applies without conflicts on usb sources. This one is used to setup device and driver without need of any hotplug scripts. 4) Initial version was made in hurry in December, but updated patch was sent and conformed by upsteam author to work. 5) The upstream author lastly updated driver in 2.6.11. Some work was made to 2.6.13, but it wasn't posted to mainline. Now author wants to update his patch set, include some more binary blobs in the driver, or use userspace helper. Anything from my patch set he may include, but i asked him to provide his update first, and then i will post my. Result: ~24k of RAM is saved, works without additional udev scripts, uses default (udev) userspace firmware load helper. Cons: User must symlink or copy firmware files from standard driver package to '/lib/firmware/'. Patches were posted in debian-kernel and can be downloaded via Gmane news gate if lost. Head of patch set thread is: Message-ID: [EMAIL PROTECTED] Archived-At: http://permalink.gmane.org/gmane.linux.debian.devel.kernel/27125 It would be nice to have this woring in Etch. Thanks. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415239: linux-image-2.6.18-4-amd64: general protection fault from powernow-k8
On Wed, Mar 21, 2007 at 06:54:55PM +1100, Hamish Moffatt wrote: [] It runs perfectly stable after 'cpufreq-set -g performance', so I don't think I can rule out the cpufreq stuff. Or ACPI, or SMP PREEMPT. Can you redo your previous observations without taining also? Maybe powernow-k8 and nvidia just can't go together. Which previous observations do you mean? Same results you've mentioned before. With either cpufreq-userspace or cpufreq-ondemand, it crashes, with or without nvidia. With cpufreq set to performance mode it is stable. I don't know of any other cases to test? So, if you are getting relieble crashes, please try * to get minimal test-case, * kernel targeted for experimental/sid: deb http://kernel-archive.buildserver.net/debian-kernel trunk main * or latest upsteam one. And please collect and send all fault logs. This can be useful, when tracing problems. There's one similar report in lkml, i've found: Archived-At: http://permalink.gmane.org/gmane.linux.kernel/474449 Message-ID: [EMAIL PROTECTED] But it have no follow-ups. Thus, as more info you can collect, more chance we can get upsteam interested. _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the -12 question
From: dann frazier Newsgroups: gmane.linux.debian.devel.kernel Subject: the -12 question Date: Wed, 21 Mar 2007 18:44:08 -0600 [] * I also propose we use the requirements in my etch-updates proposal for fixes (must have bug filed, must be important or greater) Is it possible to have a way for ti-usb serial patches (removing firmware and hotplug, tested by upsteam author) there? Shall i file a bug for that? Thanks. _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415239: linux-image-2.6.18-4-amd64: general protection fault from powernow-k8
On Mon, Mar 19, 2007 at 06:50:10PM +1100, Hamish Moffatt wrote: On Sat, Mar 17, 2007 at 07:52:37PM +0100, Oleg Verych wrote: [] Try to not use proprietary modules, powernowd daemon (use ondemand driver) and reproduce that. OK, I will try all that asap (tomorrow hopefully). Two more observations since then; 1. It does crash under heavy load, if powernow-k8 is loaded (+ powernowd + cpufreq_userspace). This daemon seems obsolete to me: last release is more than year ago, there's ondemand governor, no problems with brain-damage like sysfs. 2. If I remove the frequency govenor stuff (stop powernowd, remove all modules) then it's perfectly stable. As i saw so many problems with sysfs (in lkml), i doubt it will get better anyway. Even bug was reported against ondemand governor, and it turned to be this daemon was running (:. Why ondemand governor is bad? The tainting was caused by the nvidia module, btw. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ti_usb, firmware loader: decision from the driver author (Re: [patch 03/05] ti_usb, device setup: without any artificial errors, use configuration changing)
Dear Debian kernel team, this is decision of the driver author himself.
These corrections are to be made for upstream tree, thus, i think, it's
OK to conform patch quality for you.
Signed-off-by: Oleg Verych [EMAIL PROTECTED]
- Forwarded message from Al Borchers [EMAIL PROTECTED] -
Date: Wed, 14 Mar 2007 03:32:47 -0500
From: Al Borchers [EMAIL PROTECTED]
To: Oleg Verych [EMAIL PROTECTED]
Cc: Greg KH [EMAIL PROTECTED],
Linux USB linux-usb-devel@lists.sourceforge.net,
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [patch 03/05] ti_usb, device setup: without any artificial errors,
use configuration changing
Oleg --
I tried this on 3410 and 5052 with and without firmware--worked
great.
Please
1) Change return value to 1, rather than 0xO1E and 0xA1B.
(Clever, but it will just confuse readers.)
2) Drop (void) cast on usb_driver_set_configuration.
3) Resend the patch with a signed-off line.
Thanks for doing this--so glad we can get rid of the hotplug
script!
-- Al
Quoting Oleg Verych [EMAIL PROTECTED]:
pp-by: Oleg Verych
---
i.e. no more uGLYdev with sysfs
Alan, i'm looking forward to deal with this crutch :-E
drivers/usb/serial/ti_usb_3410_5052.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.21-rc1/drivers/usb/serial/ti_usb_3410_5052.c
===
--- linux-2.6.21-rc1.orig/drivers/usb/serial/ti_usb_3410_5052.c
2007-02-23
05:03:57.691537658 +0100
+++ linux-2.6.21-rc1/drivers/usb/serial/ti_usb_3410_5052.c2007-02-23
05:22:22.766512292 +0100
@@ -389,13 +389,13 @@
usb_reset_device(dev);
}
- status = -ENODEV;
+ status = 0x01E; /* positive status -- device to be reconfigured
*/
goto free_tdev;
}
- /* the second configuration must be set (in sysfs by hotplug script) */
if (dev-actconfig-desc.bConfigurationValue == TI_BOOT_CONFIG) {
- status = -ENODEV;
+ (void) usb_driver_set_configuration(dev, TI_ACTIVE_CONFIG);
+ status = 0xA1B;
goto free_tdev;
}
--
- End forwarded message -
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413736: usb: no configuration chosen from 1 choice
From: maximilian attems Newsgroups: gmane.linux.debian.devel.kernel Subject: Bug#413736: usb: no configuration chosen from 1 choice Date: Sat, 10 Mar 2007 09:43:26 +0100 tags 413736 wontfix stop On Tue, 06 Mar 2007, Nick Shaforostoff wrote: kernels beginning with 2.6.16 have typo in their sources, wich causes usb modem detecion to fail. kern.log says: usb 3-1: new full speed USB device using ohci_hcd and address 2 usb 3-1: no configuration chosen from 1 choice the solution is to replace #ifndef CONFIG_USB_NET_RNDIS_HOST with #ifndef CONFIG_USB_NET_RNDIS_HOST_MODULE in drivers/usb/core/hub.c -- for 2.6.18 or in drivers/usb/core/generic.c -- for 2.6.20.x i hope that etch wont be shipped with this silly error aint fixed thanks you in advance! i have zero idea about your test case in anyway as upstream has not changed that value there are zero chances to get that into etch. you'd better inform upstream in bugzilla.kernel.org Actually upstream has _little_ moving in this: Archived-At: http://permalink.gmane.org/gmane.linux.usb.devel/47056 Message-Id: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[patch 05/06] ti_usb, device setup: without any artificial errors, use configuration changing
pp-by: Oleg Verych
---
i.e. no more uGLYdev with sysfs
Alan, i'm looking forward to deal with this crutch :-E
drivers/usb/serial/ti_usb_3410_5052.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.c
===
--- linux-source-2.6.18.orig/drivers/usb/serial/ti_usb_3410_5052.c
2007-02-23 09:13:05.314141000 +0100
+++ linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.c 2007-02-23
09:13:08.846361750 +0100
@@ -387,13 +387,13 @@
usb_reset_device(dev);
}
- status = -ENODEV;
+ status = 0x01E; /* positive status -- device to be reconfigured
*/
goto free_tdev;
}
- /* the second configuration must be set (in sysfs by hotplug script) */
if (dev-actconfig-desc.bConfigurationValue == TI_BOOT_CONFIG) {
- status = -ENODEV;
+ (void) usb_driver_set_configuration(dev, TI_ACTIVE_CONFIG);
+ status = 0xA1B;
goto free_tdev;
}
--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[patch 01/06] ti_usb, usbcore: help drivers to change device
Hi, debian-kernel Developers. So far i have nothing wrong with this
patchset, only some minor bureoucracy. Thus i'm sending its other parts.
---
Greg:
It's generally a bad idea for USB interface drivers to try to change a
device's configuration, and usbcore doesn't provide any way for them
to do it. However in a few exceptional circumstances it can make
sense. This patch (as767) adds a roundabout mechanism to help drivers
that may need it.
Alan Stern
Signed-off-by: Alan Stern [EMAIL PROTECTED]
===
Right now this would be used by only one driver, so the code could be put
into that driver instead of the core. However I'm submitting it for the
core, on the theory that if one driver can find a use for it, other ones
eventually will too.
-
Yes, usbcore design is a bad idea, thus we must accept this crutch!
comment-by: Oleg Verych
---
drivers/usb/core/message.c | 59 +
include/linux/usb.h|3 ++
2 files changed, 62 insertions(+)
Index: linux-source-2.6.18/include/linux/usb.h
===
--- linux-source-2.6.18.orig/include/linux/usb.h2007-02-23
09:05:41.626412250 +0100
+++ linux-source-2.6.18/include/linux/usb.h 2007-02-23 09:12:21.45540
+0100
@@ -1038,6 +1038,9 @@
extern int usb_reset_configuration(struct usb_device *dev);
extern int usb_set_interface(struct usb_device *dev, int ifnum, int alternate);
+/* this request isn't really synchronous, but it belongs with the others */
+extern int usb_driver_set_configuration(struct usb_device *udev, int config);
+
/*
* timeouts, in milliseconds, used for sending/receiving control messages
* they typically complete within a few frames (msec) after they're issued
Index: linux-source-2.6.18/drivers/usb/core/message.c
===
--- linux-source-2.6.18.orig/drivers/usb/core/message.c 2007-02-23
09:05:41.710417500 +0100
+++ linux-source-2.6.18/drivers/usb/core/message.c 2007-02-23
09:12:21.459400250 +0100
@@ -1508,6 +1508,65 @@
return 0;
}
+struct set_config_request {
+ struct usb_device *udev;
+ int config;
+ struct work_struct work;
+};
+
+/* Worker routine for usb_driver_set_configuration() */
+static void driver_set_config_work(void *_req)
+{
+ struct set_config_request *req = _req;
+
+ usb_lock_device(req-udev);
+ usb_set_configuration(req-udev, req-config);
+ usb_unlock_device(req-udev);
+ usb_put_dev(req-udev);
+ kfree(req);
+}
+
+/**
+ * usb_driver_set_configuration - Provide a way for drivers to change device
configurations
+ * @udev: the device whose configuration is being updated
+ * @config: the configuration being chosen.
+ * Context: In process context, must be able to sleep
+ *
+ * Device interface drivers are not allowed to change device configurations.
+ * This is because changing configurations will destroy the interface the
+ * driver is bound to and create new ones; it would be like a floppy-disk
+ * driver telling the computer to replace the floppy-disk drive with a
+ * tape drive!
+ *
+ * Still, in certain specialized circumstances the need may arise. This
+ * routine gets around the normal restrictions by using a work thread to
+ * submit the change-config request.
+ *
+ * Returns 0 if the request was succesfully queued, error code otherwise.
+ * The caller has no way to know whether the queued request will eventually
+ * succeed.
+ */
+int usb_driver_set_configuration(struct usb_device *udev, int config)
+{
+ struct set_config_request *req;
+
+ req = kmalloc(sizeof(*req), GFP_KERNEL);
+ if (!req)
+ return -ENOMEM;
+ req-udev = udev;
+ req-config = config;
+ INIT_WORK(req-work, driver_set_config_work, req);
+
+ usb_get_dev(udev);
+ if (!schedule_work(req-work)) {
+ usb_put_dev(udev);
+ kfree(req);
+ return -EINVAL;
+ }
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_driver_set_configuration);
+
// synchronous request completion model
EXPORT_SYMBOL(usb_control_msg);
EXPORT_SYMBOL(usb_bulk_msg);
--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[patch 03/06] ti_usb, kconfig: describe firmware files in userspace
pp-by: Oleg Verych --- drivers/usb/serial/Kconfig | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) Index: linux-source-2.6.18/drivers/usb/serial/Kconfig === --- linux-source-2.6.18.orig/drivers/usb/serial/Kconfig 2007-02-23 09:05:44.494591500 +0100 +++ linux-source-2.6.18/drivers/usb/serial/Kconfig 2007-02-23 09:13:00.081814000 +0100 @@ -129,7 +129,7 @@ Supported microcontrollers in the CY4601 family are: CY7C63741 CY7C63742 CY7C63743 CY7C64013 - + To compile this driver as a module, choose M here: the module will be called cypress_m8. @@ -461,9 +461,18 @@ config USB_SERIAL_TI tristate USB TI 3410/5052 Serial Driver depends on USB_SERIAL + select FW_LOADER help Say Y here if you want to use the TI USB 3410 or 5052 - serial devices. + usb to serial converters or devices using them as interfaces. + + Standard setup requires firmware change. Default firmware files + from Texas Instruments' driver package are: + + * umpf3410.i51 + * umpf5052.i51 + + This files or symlinks must be placed in /lib/firmware. To compile this driver as a module, choose M here: the module will be called ti_usb_3410_5052. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[patch 02/06] ti_usb, cleanup: comments, whitespace
* Al Borchers remains one to bother with this driver,
* shell script is not needed in comments.
pp-by: Oleg Verych
---
drivers/usb/serial/ti_usb_3410_5052.c | 73 +-
drivers/usb/serial/ti_usb_3410_5052.h |3 -
2 files changed, 12 insertions(+), 64 deletions(-)
Index: linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.c
===
--- linux-source-2.6.18.orig/drivers/usb/serial/ti_usb_3410_5052.c
2007-02-23 09:05:44.450588750 +0100
+++ linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.c 2007-02-23
09:12:43.276763750 +0100
@@ -14,58 +14,7 @@
* (at your option) any later version.
*
* For questions or problems with this driver, contact Texas Instruments
- * technical support, or Al Borchers [EMAIL PROTECTED], or
- * Peter Berger [EMAIL PROTECTED].
- *
- * This driver needs this hotplug script in /etc/hotplug/usb/ti_usb_3410_5052
- * or in /etc/hotplug.d/usb/ti_usb_3410_5052.hotplug to set the device
- * configuration.
- *
- * #!/bin/bash
- *
- * BOOT_CONFIG=1
- * ACTIVE_CONFIG=2
- *
- * if [[ $ACTION != add ]]
- * then
- * exit
- * fi
- *
- * CONFIG_PATH=/sys${DEVPATH%/?*}/bConfigurationValue
- *
- * if [[ 0`cat $CONFIG_PATH` -ne $BOOT_CONFIG ]]
- * then
- * exit
- * fi
- *
- * PRODUCT=${PRODUCT%/?*} # delete version
- * VENDOR_ID=`printf %d 0x${PRODUCT%/?*}`
- * PRODUCT_ID=`printf %d 0x${PRODUCT#*?/}`
- *
- * PARAM_PATH=/sys/module/ti_usb_3410_5052/parameters
- *
- * function scan() {
- * s=$1
- * shift
- * for i
- * do
- * if [[ $s -eq $i ]]
- * then
- * return 0
- * fi
- * done
- * return 1
- * }
- *
- * IFS=$IFS,
- *
- * if (scan $VENDOR_ID 1105 `cat $PARAM_PATH/vendor_3410`
- * scan $PRODUCT_ID 13328 `cat $PARAM_PATH/product_3410`) ||
- * (scan $VENDOR_ID 1105 `cat $PARAM_PATH/vendor_5052`
- * scan $PRODUCT_ID 20562 20818 20570 20575 `cat $PARAM_PATH/product_5052`)
- * then
- * echo $ACTIVE_CONFIG $CONFIG_PATH
- * fi
+ * technical support, or Al Borchers [EMAIL PROTECTED].
*/
#include linux/kernel.h
@@ -253,7 +202,7 @@
.probe = usb_serial_probe,
.disconnect = usb_serial_disconnect,
.id_table = ti_id_table_combined,
- .no_dynamic_id =1,
+ .no_dynamic_id =1,
};
static struct usb_serial_driver ti_1port_device = {
@@ -451,7 +400,7 @@
status = -ENODEV;
goto free_tdev;
- }
+ }
/* the second configuration must be set (in sysfs by hotplug script) */
if (dev-actconfig-desc.bConfigurationValue == TI_BOOT_CONFIG) {
@@ -486,7 +435,7 @@
usb_set_serial_port_data(serial-port[i], tport);
tport-tp_uart_mode = 0;/* default is RS232 */
}
-
+
return 0;
free_tports:
@@ -533,8 +482,8 @@
struct urb *urb;
int port_number;
int status;
- __u16 open_settings = (__u8)(TI_PIPE_MODE_CONTINOUS |
-TI_PIPE_TIMEOUT_ENABLE |
+ __u16 open_settings = (__u8)(TI_PIPE_MODE_CONTINOUS |
+TI_PIPE_TIMEOUT_ENABLE |
(TI_TRANSFER_TIMEOUT 2));
dbg(%s - port %d, __FUNCTION__, port-number);
@@ -550,7 +499,7 @@
return -ERESTARTSYS;
if (port-tty)
- port-tty-low_latency =
+ port-tty-low_latency =
(tport-tp_flags ASYNC_LOW_LATENCY) ? 1 : 0;
port_number = port-number - port-serial-minor;
@@ -676,7 +625,7 @@
int do_up;
dbg(%s - port %d, __FUNCTION__, port-number);
-
+
tdev = usb_get_serial_data(port-serial);
tport = usb_get_serial_port_data(port);
if (tdev == NULL || tport == NULL)
@@ -749,7 +698,7 @@
if (tport == NULL)
return -ENODEV;
-
+
spin_lock_irqsave(tport-tp_lock, flags);
room = ti_buf_space_avail(tport-tp_write_buf);
spin_unlock_irqrestore(tport-tp_lock, flags);
@@ -956,7 +905,7 @@
}
} else {
config-wFlags = ~TI_UART_ENABLE_PARITY_CHECKING;
- config-bParity = TI_UART_NO_PARITY;
+ config-bParity = TI_UART_NO_PARITY;
}
if (cflag CSTOPB)
@@ -1336,7 +1285,7 @@
result = usb_submit_urb(port-write_urb, GFP_ATOMIC);
if (result) {
dev_err(port-dev, %s - submit write urb failed, %d\n,
__FUNCTION__, result);
- tport-tp_write_urb_in_use = 0;
+ tport-tp_write_urb_in_use = 0;
/* TODO: reschedule ti_send */
} else {
spin_lock_irqsave(tport-tp_lock, flags);
Index: linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.h
[patch 06/06] ti_usb, copyright update: if it deserves
pp-by: Oleg Verych --- drivers/usb/serial/ti_usb_3410_5052.c |4 ++-- drivers/usb/serial/ti_usb_3410_5052.h |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) Index: linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.c === --- linux-source-2.6.18.orig/drivers/usb/serial/ti_usb_3410_5052.c 2007-02-23 09:13:08.846361750 +0100 +++ linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.c 2007-02-23 09:13:12.814609750 +0100 @@ -1,8 +1,8 @@ -/* vi: ts=8 sw=8 - * +/* * TI 3410/5052 USB Serial Driver * * Copyright (C) 2004 Texas Instruments + * Copyright (C) 2007 Oleg Verych * * This driver is based on the Linux io_ti driver, which is * Copyright (C) 2000-2002 Inside Out Networks Index: linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.h === --- linux-source-2.6.18.orig/drivers/usb/serial/ti_usb_3410_5052.h 2007-02-23 09:13:05.310140750 +0100 +++ linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.h 2007-02-23 09:13:12.814609750 +0100 @@ -1,8 +1,8 @@ -/* vi: ts=8 sw=8 - * +/* * TI 3410/5052 USB Serial Driver Header * * Copyright (C) 2004 Texas Instruments + * Copyright (C) 2007 Oleg Verych * * This driver is based on the Linux io_ti driver, which is * Copyright (C) 2000-2002 Inside Out Networks -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[patch 04/06] ti_usb, changing firmware: adopting userspace helper
pp-by: Oleg Verych
---
drivers/usb/serial/ti_usb_3410_5052.c | 148 +-
drivers/usb/serial/ti_usb_3410_5052.h | 27 +++---
2 files changed, 109 insertions(+), 66 deletions(-)
Index: linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.h
===
--- linux-source-2.6.18.orig/drivers/usb/serial/ti_usb_3410_5052.h
2007-02-23 09:12:43.276763750 +0100
+++ linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.h 2007-02-23
09:13:05.310140750 +0100
@@ -21,8 +21,8 @@
#define _TI_3410_5052_H_
/* Configuration ids */
-#define TI_BOOT_CONFIG 1
-#define TI_ACTIVE_CONFIG 2
+#define TI_BOOT_CONFIG 1 /* boot config to get firmware */
+#define TI_ACTIVE_CONFIG 2 /* actual working device config */
/* Vendor and product ids */
#define TI_VENDOR_ID 0x0451
@@ -206,19 +206,24 @@
#define TI_CODE_DATA_ERROR 0x03
#define TI_CODE_MODEM_STATUS 0x04
-/* Download firmware max packet size */
-#define TI_DOWNLOAD_MAX_PACKET_SIZE64
-
-/* Firmware image header */
-struct ti_firmware_header {
- __le16 wLength;
- __u8bCheckSum;
-} __attribute__((packed));
-
/* UART addresses */
#define TI_UART1_BASE_ADDR 0xFFA0 /* UART 1 base address */
#define TI_UART2_BASE_ADDR 0xFFB0 /* UART 2 base address */
#define TI_UART_OFFSET_LCR 0x0002 /* UART MCR register offset */
#define TI_UART_OFFSET_MCR 0x0004 /* UART MCR register offset */
+/* Firmware */
+#define TI_FW_PACKET_SIZE 64
+#define TI_MAX_FIRMWARE_SIZE 16284
+
+#define ti_fw_file_3410umpf3410.i51
+#define ti_fw_file_5052umpf5052.i51
+
+typedef union {
+ __le32 a; /* all */
+ struct {
+ __le32 sz : 16, cs : 8;
+ } d;
+} ti_firmware_header_t;
+
#endif /* _TI_3410_5052_H_ */
Index: linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.c
===
--- linux-source-2.6.18.orig/drivers/usb/serial/ti_usb_3410_5052.c
2007-02-23 09:12:43.276763750 +0100
+++ linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.c 2007-02-23
09:13:05.314141000 +0100
@@ -33,20 +33,15 @@
#include asm/semaphore.h
#include linux/usb.h
#include linux/usb/serial.h
-
+#include linux/firmware.h
#include ti_usb_3410_5052.h
-#include ti_fw_3410.h/* firmware image for 3410 */
-#include ti_fw_5052.h/* firmware image for 5052 */
-
/* Defines */
-#define TI_DRIVER_VERSION v0.9
+#define TI_DRIVER_VERSION v0.92
#define TI_DRIVER_AUTHOR Al Borchers [EMAIL PROTECTED]
#define TI_DRIVER_DESC TI USB 3410/5052 Serial Driver
-#define TI_FIRMWARE_BUF_SIZE 16284
-
#define TI_WRITE_BUF_SIZE 1024
#define TI_TRANSFER_TIMEOUT2
@@ -143,8 +138,7 @@
static int ti_write_byte(struct ti_device *tdev, unsigned long addr,
__u8 mask, __u8 byte);
-static int ti_download_firmware(struct ti_device *tdev,
- unsigned char *firmware, unsigned int firmware_size);
+static int ti_fw_change(struct ti_device *tdev, const char *filename);
/* circular buffer */
static struct circ_buf *ti_buf_alloc(void);
@@ -382,13 +376,8 @@
/* if we have only 1 configuration, download firmware */
if (dev-descriptor.bNumConfigurations == 1) {
-
- if (tdev-td_is_3410)
- status = ti_download_firmware(tdev, ti_fw_3410,
- sizeof(ti_fw_3410));
- else
- status = ti_download_firmware(tdev, ti_fw_5052,
- sizeof(ti_fw_5052));
+ status = ti_fw_change(tdev, tdev-td_is_3410 ?
+ ti_fw_file_3410 : ti_fw_file_5052);
if (status)
goto free_tdev;
@@ -1594,57 +1583,106 @@
}
-static int ti_download_firmware(struct ti_device *tdev,
- unsigned char *firmware, unsigned int firmware_size)
+static int ti_fw_change(struct ti_device *tdev, const char *filename)
{
- int status = 0;
- int buffer_size;
- int pos;
- int len;
- int done;
- __u8 cs = 0;
- __u8 *buffer;
- struct usb_device *dev = tdev-td_serial-dev;
- struct ti_firmware_header *header;
- unsigned int pipe = usb_sndbulkpipe(dev,
- tdev-td_serial-port[0]-bulk_out_endpointAddress);
+#define udev (tdev-td_serial-dev)
+#define fw_endpoint(tdev-td_serial-port[0]-bulk_out_endpointAddress)
+ const struct firmware *fw_data_ptr;
+ size_t size;
+ int w;
- buffer_size = TI_FIRMWARE_BUF_SIZE + sizeof(struct ti_firmware_header);
- buffer = kmalloc(buffer_size, GFP_KERNEL);
- if (!buffer) {
- dev_err(dev-dev
[patch 00/06] ti_usb, usb-serial: firmware in userspace, new setup/configuration, small cleanup
Thankfully to Al, who have some time to test this, i'm pleased to send this patch proposition. Debian. This update eliminates need of udev/sysfs reconfiguration, thus no udev package patches needed. Firmware files from standard driver package from TI must be copied or symlinked to /lib/firmware. Patchset was posted to usb-devel (but not yet appeared) and to maintainers. Debian's kernel's ready patch set can be sent to you. Thanks. ,-*- dmesg -*- |usbcore: registered new driver ti_usb_3410_5052 |/mnt/work/root-fs/usr/src/linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.c: |TI USB 3410/5052 Serial Driver v0.92 |ti_usb_3410_5052 3-2:1.0: device disconnected |usb 3-2: new full speed USB device using ohci_hcd and address 3 |usb 3-2: configuration #1 chosen from 2 choices |ti_usb_3410_5052 3-2:1.0: TI USB 3410 1 port adapter converter detected |ti_usb_3410_5052 3-2:1.0: device disconnected |ti_usb_3410_5052 3-2:2.0: TI USB 3410 1 port adapter converter detected |usb 3-2: TI USB 3410 1 port adapter converter now attached to ttyUSB0 `-*- -- -o--=O`C info emacs : not found #oo'L O info make : not found ___=E M man gcc: not found -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
2.6.18.8 stable++ (Re: Bug#406111: Pretty please, backport!)
From: maximilian attems Newsgroups: gmane.linux.debian.devel.kernel Subject: Bug#406111: Pretty please, backport! Date: Sat, 17 Feb 2007 19:53:01 +0100 Hallo. [] the etch kernel is frozen. nevertheless cherrypicking the important patch may qualify for a stable release update. Just in case somebody cares. Subject: Re: [stable] [patch 00/18] 2.6.18-stable review Message-ID: [EMAIL PROTECTED] Archived-At: http://permalink.gmane.org/gmane.linux.kernel/496205 Message-ID: [EMAIL PROTECTED] Archived-At: http://permalink.gmane.org/gmane.linux.kernel/496520 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307517: [ Bug#409934: kernel-image-2.6.8-3-686-smp: system crash with message kernel BUG at mm/rmap.c:407]
From: dann frazier Newsgroups: gmane.linux.debian.devel.kernel Subject: Bug#307517: [EMAIL PROTECTED]: Bug#409934: kernel-image-2.6.8-3-686-smp: system crash with message kernel BUG at mm/rmap.c:407] Date: Tue, 6 Feb 2007 11:02:41 -0700 Package: kernel-image-2.6.8-3-686-smp Version: 2.6.8-16sarge6 Severity: critical Justification: breaks the whole system it have been the second time the sistem crash with this error. Feb 5 18:18:04 merlot kernel: [ cut here ] Feb 5 18:18:04 merlot kernel: kernel BUG at mm/rmap.c:407! Feb 5 18:18:04 merlot kernel: invalid operand: [#1] Feb 5 18:18:04 merlot kernel: PREEMPT SMP If anyone cares, i think this is a kind of race due to PREEMPT. Maybe this is relevant to solve this. But new kernel, of course, is more appriciated. http://git2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=508034a32b819a2d40aa7ac0dbc8cd2e044c2de6 [PATCH] mm: unmap_vmas with inner ptlock Well, there are some more race fixes noted in the git history of mm/memory.c. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [patch, attach, RFC] usb-serial: ti_usb removing firmware
Hallo, Al. After your comments (mostly minor) about patch, you've said, that you will try to test it. Did you manage to do so or not? I'm going to send you whitespace-cleanup.patch, req_firm.patch, will you accept and test them? Maybe it will be accepted to the Debian. TIA. -- -o--=O`C #oo'L O ___=E M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [patch, attach, RFC] usb-serial: ti_usb removing firmware
On 12/20/06, Al Borchers [EMAIL PROTECTED] wrote: Oleg -- Quoting Oleg Verych [EMAIL PROTECTED]: On 12/16/06, Al Borchers [EMAIL PROTECTED] wrote: * +#define TI_3410_EZ430_ID 0xF430 /* TI ez430 development tool */ Where do you use this? Shiny new device from TI, don't you know? You've lost nothing MSP430 Design Contest is over ;D www.designmsp430.com Does the EZ430 use the same firmware as in ti_fw_3410.h, or is it different? Sorry for a small traces of my ez430 ID patch there. It was sent two months ago for debian and linux-usb. http://article.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/5733 As far as i can see, ti-usb-serial is a hardware interface there, thus it uses standard usb-serial converter firmware. -- -o--=O`C #oo'L O ___=E M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [patch, attach, RFC] usb-serial: ti_usb removing firmware
On 12/16/06, Al Borchers [EMAIL PROTECTED] wrote: Oleg -- Some comments. I will be away until next Tuesday, when I can do more with this. Thanks. * We can't remove the compiled in firmware--that would break things until users get and install the firmware images. * What I did in my patch at www.brimson.com/downloads/ti_usb_multitech-1.1.tgz is to use request_firmware for new devices, and, if the firmware files are present, for the existing 3410 and 5052 devices. If the firmware files are not present for 3410 and 5052, then it uses the compiled in firmware. Please, see this as policy, not as the need (this here is no binary blobs in the linux sources symlink your windowz firmware files in /lib/firmware. Please see my last e-mail.) I can understand all cases handling in application programming, but not here. [...] * The whitespace, 80 cols, dbg cleanup is great--maybe put that in a separate patch. emacs, and this is problem with linux/Makefile (my first ever code-patch for linux ;) * I would not remove the comments about the hotplug script until we can use the 2.6.19 usb_driver_set_configuration function. Please see my last e-mail [1]. And many useless code must be copies for every ID. * - status = -ENODEV; + status = 0xFAC; /* greater than zero -- device is going down */ - status = -ENODEV; + status = 0x0FF; Why 0xFAC and 0x0FF? I will have to investigate and test this. I think we want negative values. Please see my last e-mail [1]. Serial-converter device _is_ made to be that way, and configuration steps must be good steps. With error codes you did that as error, _two_ I/O errors is very much for ordinary setup of the plugged-in device, do you see my point? * + dev_info(dev-dev, %s - Choose configuration #2, please.\n, +ti_usb_driver.name); + This is what the hotplug script does automatically. Drop this info message. Yes. (in my prev. e-mail [1]) I said, that most people can use bash and not udev. * Using smaller buffers in download_firmware sounds like a good idea. I will look at that next week--no time tonight. * +#define TI_3410_EZ430_ID 0xF430 /* TI ez430 development tool */ Where do you use this? Shiny new device from TI, don't you know? You've lost nothing MSP430 Design Contest is over ;D www.designmsp430.com Thanks, -- Al Thank you very much, Al. But if debian guys do not against, i think it can be in the Etch, there isn't any crap in patch. [1] http://article.gmane.org/gmane.linux.usb.devel/49186 -- -o--=O`C #oo'L O ___=E M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [patch, attach, RFC] usb-serial: ti_usb removing firmware
On 12/14/06, Greg KH [EMAIL PROTECTED] wrote: On Thu, Dec 14, 2006 at 11:10:46PM +0200, Oleg Verych wrote: Hallo. Due to very big distance to my usual work stand, please accept this. Hm, I don't think this driver is orphaned. Please work with Al to get this accepted through him, I'll have to wait for his ACK on it. After my ID patch, i don't think so. After not having sem-mutex, i don't think so. After some other issues, i don't think so. Maybe that just was summer. Mister Al, please review my patch (here http://article.gmane.org/gmane.linux.usb.devel/49174). All comments are welcome. I hope this will be nice little good for Debian... -- -o--=O`C #oo'L O ___=E M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [linux-usb-devel] [patch, attach, RFC] usb-serial: ti_usb removing firmware
On 12/15/06, Oliver Neukum [EMAIL PROTECTED] wrote:
Am Freitag, 15. Dezember 2006 10:30 schrieb Oleg Verych:
On 12/14/06, Greg KH [EMAIL PROTECTED] wrote:
On Thu, Dec 14, 2006 at 11:10:46PM +0200, Oleg Verych wrote:
Hallo. Due to very big distance to my usual work stand, please accept
this.
Hm, I don't think this driver is orphaned. Please work with Al to get
this accepted through him, I'll have to wait for his ACK on it.
After my ID patch, i don't think so. After not having sem-mutex, i
don't think so.
After some other issues, i don't think so. Maybe that just was summer.
Mister Al, please review my patch (here
http://article.gmane.org/gmane.linux.usb.devel/49174).
All comments are welcome. I hope this will be nice little good for Debian...
It also creates an incompatibility between kernel versions and needs
I would like to know how it creates that. I wanted to make as little
changes as possible.
the firmware distributed separately. Have you made patches to the
Debian developer's question? Heh ;)
Every such (complex or simple interface) device _have_ drivers for
Offtopic System.
Firmware files(1) are there under filenames i used in the patch.
And btw, how many bug reports for ti_usb driver are there in the BTS?
http://merkel.debian.org/~don/cgi/search.cgi?phrase=ti_usb_3410_5052search=searchskip=0order_field=order_operator=STRAmax_results=10
Only users i know, are in mspgcc mailing list. And i know what it took
developers of GCC
for msp430 to configure _this_ driver (don't check summer archives,
it was very hard, and
nobody sent a patch to buggy parameter parsing, udev, etc...) This
list of beautiful users
is added..
relevant packages and waited for them to be included into actual releases?
Well, do you mean udev? AFAIK Debian has no support for this udriver.
Symlinks of (1) to /lib/firmware/ _is_ enough. And after reading
dmesg (without stupid I/O error messages from old driver), user knows
that actual working
configuration is the second one, and anyone now can add
`echo 2 /big/deep/ass/../bConfigValue`.
In case if somebody will use udev (ez430 id patch included):
,--[/etc/udev/rules.d/077-ez430.udev.rules]--
|SUBSYSTEM==usb_device ACTION==add \
|SYSFS{idVendor}==0451 SYSFS{idProduct}==f430 \
|SYSFS{bNumConfigurations}==2 SYSFS{bConfigurationValue}==1 \
|RUN+=/bin/sh -c 'echo 2 /sys/%p/device/bConfigurationValue'
`
I don't use it (well, trying to do so).
Mister Greg, how to change configuration _inside_ the driver? Device
was made to be
working on second usb config after one reconnect/device change, i've
lost whole day
trying to make something with that. After all, usb_set_configuration()
isn't even
EXPORT()ED at all !
Are you handling the mails that report a device no longer working?
Yes, if i would on my working stand. Ideas were right after summer
events in mspgcc list,
but i decided to start kernel development first and stuck with kbuild
fixes, lost much time.
Now i'm long away due to loss of my close man. Nearly month ago, before package
freezing, i've made much of this, but now i'm on very short internet
and work access.
How much memory does the patch save?
Static memory ~28k. And hey, this is firmware, by the way (and i don't
suggest you to
look on sources of it, very ugly in short, but working anyways ;).
From stack usage point
of view, ti_download_firmware() was cut on some pointers and variables, but
request_firmware() was added, so i don't know exactly.
request_firmware() is allocating
buffer in virtual memory (usb download needs kmalloced one, ugly
solution for firmwares
usually 2-4 4k pages thick), another problem.
Making Debian happy is not very high on the list of goals.
Yes, thanks for the hint. I'm having enough after documentation removing...
Regards
Oliver
Sorry for long mail, cc list and little benefit, if any.
--
-o--=O`C
#oo'L O
___=E M
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[patch, attach, RFC] usb-serial: ti_usb removing firmware
Hallo. Due to very big distance to my usual work stand, please accept this. -- -o--=O`C #oo'L O ___=E M usb-serial-ti_usb-move_firmware_to_userspace.patch.gz Description: GNU Zip compressed data
Re: preparation for 2.6.18-6 kernel upload on monday 20th of november 2006.
On 2006-11-16, Sven Luther wrote: Hi, ... As you may know, or not, we are waiting for the abi-breaking 2.6.18-6 to be uploaded for pushing the 2.6.18 kernel into etch. It seems 2.6.18.3 is announced for saturday, so this would mean a natural tentative schedule of let's say monday the 20th of november 2006 as upload date. Is there any comment on this ? Anyone has any particular stuff they would like included before -6 is released ? Or otherwise comments on this tentative deadline ? I have patch. Will be 2.6.20, as i was too late for .19. http://permalink.gmane.org/gmane.linux.usb.devel/48353 Can it be included, it's not stable stuff, as i was told? Id of the patch is [EMAIL PROTECTED]. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[patch] ti_usb id (Re: preparation for 2.6.18-6 kernel upload on monday 20th of november 2006.)
On Sat, Nov 18, 2006 at 12:58:12PM +0100, Sven Luther wrote:
On Sat, Nov 18, 2006 at 09:53:28AM +, Oleg Verych wrote:
On 2006-11-16, Sven Luther wrote:
Hi, ...
As you may know, or not, we are waiting for the abi-breaking 2.6.18-6 to
be
uploaded for pushing the 2.6.18 kernel into etch.
It seems 2.6.18.3 is announced for saturday, so this would mean a natural
tentative schedule of let's say monday the 20th of november 2006 as upload
date.
Is there any comment on this ? Anyone has any particular stuff they would
like
included before -6 is released ? Or otherwise comments on this tentative
deadline ?
I have patch. Will be 2.6.20, as i was too late for .19.
http://permalink.gmane.org/gmane.linux.usb.devel/48353
What does it do ? Just new id for an usb tool ? The description says :
usb-serial: ti_usb, TI ez430 development tool ID
Yes, to enable hotplug and driver to see that usb device.
Driver is unmaintained a little bit, there is a bug with interpretation
of module parameters, thus i want to push this patch, so users (there are
a little number of us) may use it.
Development tool is controller + programmer + debugger in usb-stick
form factor.
Can it be included, it's not stable stuff, as i was told?
Id of the patch is [EMAIL PROTECTED].
Well, can you post the full patch ?
Friendly,
Sven Luther
It will be nice to have this in etch. Thanks.
usb-serial: ti_usb, TI ez430 development tool ID
Cc: Greg KH [EMAIL PROTECTED]
Signed-off-by: Oleg Verych [EMAIL PROTECTED]
---
Please apply to stable and rc kernels. Thanks.
drivers/usb/serial/ti_usb_3410_5052.c |2 ++
drivers/usb/serial/ti_usb_3410_5052.h |1 +
2 files changed, 3 insertions(+)
Index: linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.c
===
*** linux-source-2.6.18.orig/drivers/usb/serial/ti_usb_3410_5052.c
2006-11-17 08:54:28.378314000 +0100
--- linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.c 2006-11-17
07:10:45.0 +0100
***
*** 228,233
--- 228,234
/* null entry */
static struct usb_device_id ti_id_table_3410[1+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
+ { USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
};
static struct usb_device_id ti_id_table_5052[4+TI_EXTRA_VID_PID_COUNT+1] = {
***
*** 239,244
--- 240,246
static struct usb_device_id ti_id_table_combined[] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
+ { USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_BOOT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_5152_BOOT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_EEPROM_PRODUCT_ID) },
Index: linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.h
===
*** linux-source-2.6.18.orig/drivers/usb/serial/ti_usb_3410_5052.h
2006-11-17 08:54:25.402128000 +0100
--- linux-source-2.6.18/drivers/usb/serial/ti_usb_3410_5052.h 2006-11-17
08:49:40.0 +0100
***
*** 28,33
--- 28,34
/* Vendor and product ids */
#define TI_VENDOR_ID 0x0451
#define TI_3410_PRODUCT_ID0x3410
+ #define TI_3410_EZ430_ID 0xF430 /* TI ez430 development tool */
#define TI_5052_BOOT_PRODUCT_ID 0x5052 /* no EEPROM, no
firmware */
#define TI_5152_BOOT_PRODUCT_ID 0x5152 /* no EEPROM, no
firmware */
#define TI_5052_EEPROM_PRODUCT_ID 0x505A /* EEPROM, no firmware */
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396185: sky2 freezes in 2.6.17-2-686. Maintainer confirms that it should be fixed in 2.6.19-git tree.
On 2006-11-18, Evgeniy Polyakov wrote: [] Hopefully they both are fixed in 2.6.18-2. I will set it up as soon as time permits (it is my main desktop, which is rarely turned off) and report if problem still persists. Note, that actual version is 2.6.18-5, and will be -6 next week. 2.6.18-2 is package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396185: sky2 network driver freezes
On 2006-10-30, Adrian Johnson wrote: [] Package: linux-image-2.6.18-1-amd64 Version: 2.6.18-4~snapshot.7648 I have experienced a network freeze of the sky2 network driver The console error message is: NETDEV WATCHDOG : eth0: transmit timed out sky2 eth0: tx timeout sky2 hardware hung? flushing [] OK. Thread on LKML has ended with this (you can browse down it a bit also). http://permalink.gmane.org/gmane.linux.kernel/456936 I don't know if pci mmconfig patch was reverted in 2.6.18.1 (it wasn't according to kernel.org's changelog) debian tree (also didn't see that). If you can, please revert it and try to get bug or more info. 2.6.19-rcX has that patch reverted, see commit: 7bd656d12119708b37414bf909ab2995473da818 If this will solve your problem, this should go to 2.6.18-4. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.18-3
On 2006-10-31, maximilian attems wrote: [] May i ask, what is general rules to accept changes? you didn't look at the wiki heh http://wiki.debian.org/DebianKernel http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines Thanks. For example .19-rc linux kernel has some valuable changes in drivers, that can support more hardware (in my case Realtek gigabit ethernet and Intel SATA, all in one box ;) Is it possible to accept some backports ? the r8169 fixes are all backported afaik. what sata fixes are you pointing too, be more precise? OK, it's all seems OK now. (i've used .19-rcX on the new machine, to bring it up; now i've installed 2.6.18-3, rebooted) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Schedule for linux-2.6 2.6.18-4
On 2006-10-30, Frederik Schueler wrote: [] I personally have somewhat lost the overview on on open issues being=20 busy with RL work the past 2 weeks, so I would like everyone of you to compile a short list of things you have on your agenda for 2.6.18-4,=20 and generally before the release. I will not resend, please find my message to you, Frederik, for 18-3: Message-ID: [EMAIL PROTECTED] http://permalink.gmane.org/gmane.linux.debian.devel.kernel/23077 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.18-3
Hallo, Frederik. On 2006-10-10, Frederik Schueler wrote: [] As usual, if someone needs more time for pending changes, drop a line. May i ask, what is general rules to accept changes? For example .19-rc linux kernel has some valuable changes in drivers, that can support more hardware (in my case Realtek gigabit ethernet and Intel SATA, all in one box ;) Is it possible to accept some backports ? Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On 2006-10-08, John Kelly wrote: On 2006-10-07, Oleg Verych wrote: binary-firmware must be removed, or 15+ years of Debian are wasted If you want to re-live the past 15 years, take your own advice: let them have own built kernel and do it yourself. Hm. I have no problems doing this, really. What i wrote was about DFSG (i.e main archive) and installation. As for me, I want to make progress, to etch and a 2.6.18 kernel. The debian kernel maintainers have a practical solution, and I agree with them. [sounds ubuntu-like, but no flamewars, please] And this is possible without any *firmware* in debian/main and installation process. I will support .18 in etch as much as i can. BTW, even .18 isn't enough for modern (0-1 year) office PCs, and there are doubts about backporting stuff from new upsteam. For example i have such PC, which require some new bytes from new r8169.c. Will kernel team backport that? I doubt it. Anyways, more frequent releases aren't much for old-good servers, IMHO. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On 2006-10-08, John Kelly wrote: On Sun, 8 Oct 2006 14:57:46 + (UTC), Oleg Verych And this is possible without any *firmware* in debian/main and installation process. Many things are possible for those doing the work. Are you doing the work? Maybe, yes. There was one message here, but nobody cared. Message-ID: [EMAIL PROTECTED] Archived-At: http://permalink.gmane.org/gmane.linux.debian.devel.kernel/21781 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#390695: linux-image-2.6.18-1-686: weird messages upon loading the CD-ROM driver[1~
On 2006-10-06, Hilmar Preusse [EMAIL PROTECTED] wrote: On 05.10.06 Oleg Verych ([EMAIL PROTECTED]) wrote: On Thu, Oct 05, 2006 at 09:49:58AM +0200, Hilmar Preusse wrote: Hi, Are the ready made Debian packages or do I have to build myself? I will, but it will be my first one (in the .deb). And i don't know how it will run, because i must cross compile on x86-64. Anyway, lets see what will happen ;) I tried to build an 19-rc1 kernel today. As I used the Debian default config and the box is not that fast it took a few hours. Then I forgot to create the initrd... :-( Will try again on Monday using kernel-package. Maybe it will be better if i'll (cross) compile some modules from backported sources for you and you will backup yours, and copy that in /lib/modules/$LINUX_VERSION? Also it's better to organize `/etc/initramfs-tools/modules' from your's current lsmod and testing `initramfs.conf' with `MODULES=list', thus you will have working-testing initrd, and boot option break=init (or mount, see initramfs-tools(8)) will bring shell to you and you can scroll boot messages or dmesg | more. The box has rather experimental status. Hmm, I should rather make a backup of /home before booting into rc1... no need, if `break' boot option used. And all we need is just driver loading, no files system or other things. H. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
testing kernels (was Re: Bug#390616: linux-image-2.6.18: Enable ATA-Security for Sid kernels)
Hallo. On 2006-10-05, Sven Luther wrote: On Thu, Oct 05, 2006 at 07:56:04PM +0200, maximilian attems wrote: that is _not_ massive testing. massive testing would be to have an debian-installer rc, with the specific option turned on. for that it is to late as the next d-i won't use 2.6.18. Which is an error, since we plan to release with a 2.6.18 kernel, and doing an d-i rc round with a kernel we won't release with is pure waste of time. What about making tesing kernels without setting module version ? Maybe this sounds stupid, but hey! Need mode testers with always with modules kernel ? Then, why not to try module from newer kernel first ? User doen't need any huge work and downloading. You ship new (f.e. new driver) module, * user adds it in /etc/initramfs-tools/modules * save old and update-initramfs -u, * do what ever need for bootloader, and system is ready for test-boot. Drivers are first candidates, hardware problems are very common, rather than build/regression/kernel-subsystems problems. Last is for lkml testers. I think upstream testing -mm tree will fail, they are using patches, because there are really huge changes in ABI, but stable (well, stable) kernel usually OK. Comments ? -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sky2 stops working 2.6.17 or ethernet driver crashes 2.6.18
[Let me CC, you guys. If not, please, reply with NACK. Thanks.] Two debian bugs Bug#390248, Bug#391382 are about failing sky2 under load. Please see, bugs.debian.org or i can forward every mail separately here. http://permalink.gmane.org/gmane.linux.debian.devel.kernel/22665 http://permalink.gmane.org/gmane.linux.debian.devel.kernel/22874 Bug#391382 is as this: On 2006-10-06, Matthias Kreis [EMAIL PROTECTED] wrote: Package: linux-image-2.6.17-2-k7 Version: 2.6.17-9 Severity: normal The Sky2 driver stops working while under load after some time. I get the following messages: sky2 eth0: rx error, status 0x7ffc0001 length 932 sky2 eth0: rx error, status 0x7ffc0001 length 932 sky2 eth0: rx error, status 0x7ffc0001 length 932 A ping to an other server results in Destination Host not Reachable from my local machine. You can solve this situation by bringing down the interface, unloading the driver, loading the driver again and bringing up the interface. Just cycling the interface down and up is not enough. You get the following messages by doing this. First was cycling down and up. Second was down, reload driver and bringing network up again. --- First Step --- nfs: server ponder not responding, still trying nfs: server ponder not responding, still trying nfs: server ponder not responding, still trying nfs: server ponder not responding, still trying sky2 eth0: disabling interface bridge-eth0: disabling the bridge bridge-eth0: down sky2 eth0: enabling interface bridge-eth0: enabling the bridge bridge-eth0: up sky2 eth0: Link is up at 1000 Mbps, full duplex, flow control both sky2 unknown status opcode 0xe1 sky2 eth0: rx error, status 0x8329ddaf length 54500 eth0: no IPv6 routers present --- Second Step --- sky2 eth0: disabling interface bridge-eth0: disabling the bridge bridge-eth0: down ACPI: PCI interrupt for device :05:00.0 disabled ACPI: PCI Interrupt :05:00.0[A] - GSI 36 (level, low) - IRQ 82 PCI: Setting latency timer of device :05:00.0 to 64 sky2 v1.6.1 addr 0xdc00 irq 82 Yukon-EC (0xb6) rev 2 sky2 eth0: addr 00:13:d4:9d:66:1d sky2 eth0: enabling interface ADDRCONF(NETDEV_UP): eth0: link is not ready bridge-eth0: enabling the bridge bridge-eth0: up sky2 eth0: Link is up at 1000 Mbps, full duplex, flow control both ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present nfs: server ponder OK nfs: server ponder OK nfs: server ponder OK nfs: server ponder OK -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (1001, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-k7 Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.17-2-k7 depends on: ii initramfs-tools [linux-initra 0.80 tools for generating an initramfs ii module-init-tools 3.2.2-3tools for managing Linux kernel mo Versions of packages linux-image-2.6.17-2-k7 recommends: ii libc6-i686 2.3.6.ds1-4 GNU C Library: Shared libraries [i -- debconf information: linux-image-2.6.17-2-k7/postinst/old-system-map-link-2.6.17-2-k7: true shared/kernel-image/really-run-bootloader: true linux-image-2.6.17-2-k7/preinst/overwriting-modules-2.6.17-2-k7: true linux-image-2.6.17-2-k7/prerm/removing-running-kernel-2.6.17-2-k7: true linux-image-2.6.17-2-k7/postinst/kimage-is-a-directory: linux-image-2.6.17-2-k7/postinst/create-kimage-link-2.6.17-2-k7: true linux-image-2.6.17-2-k7/prerm/would-invalidate-boot-loader-2.6.17-2-k7: true linux-image-2.6.17-2-k7/preinst/already-running-this-2.6.17-2-k7: linux-image-2.6.17-2-k7/preinst/failed-to-move-modules-2.6.17-2-k7: linux-image-2.6.17-2-k7/preinst/bootloader-initrd-2.6.17-2-k7: true linux-image-2.6.17-2-k7/postinst/old-initrd-link-2.6.17-2-k7: true linux-image-2.6.17-2-k7/preinst/abort-overwrite-2.6.17-2-k7: linux-image-2.6.17-2-k7/postinst/depmod-error-2.6.17-2-k7: false linux-image-2.6.17-2-k7/postinst/old-dir-initrd-link-2.6.17-2-k7: true linux-image-2.6.17-2-k7/preinst/lilo-initrd-2.6.17-2-k7: true linux-image-2.6.17-2-k7/preinst/abort-install-2.6.17-2-k7: linux-image-2.6.17-2-k7/postinst/bootloader-error-2.6.17-2-k7: linux-image-2.6.17-2-k7/preinst/initrd-2.6.17-2-k7: linux-image-2.6.17-2-k7/postinst/depmod-error-initrd-2.6.17-2-k7: false linux-image-2.6.17-2-k7/preinst/lilo-has-ramdisk: linux-image-2.6.17-2-k7/postinst/bootloader-test-error-2.6.17-2-k7: linux-image-2.6.17-2-k7/preinst/elilo-initrd-2.6.17-2-k7: true Best Regards Matthias Kreis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390541: linux-image-2.6.17-2-686: 2.6.17 fails to detect PIONEER DVD-RW DVR-K15, works fine with 2.6.16
On Tue, Oct 03, 2006 at 04:30:13PM +0200, Georg Wittenburg wrote: Hi Oleg! On Tuesday 03 October 2006 16:24, you wrote: On 2006-10-02, Georg Wittenburg [EMAIL PROTECTED] wrote: [.] Please don't be so selfish ;), attach full bootlog (dmesg + mount output). Here i see hdb, that means device node for your drive set up. What's problem, is not clear. [.] No problem. ;) Please find attached to complete dmesg output of 2.6.16, 2.6.17 and 2.6.18. 2.6.16 works as expected, 2.6.17 and 2.6.18 fail to detect the DVD drive. OK, but before will go further with this, can you give 2.6.19-rc1 a try ? 2.6.18 had very long cycle, maybe that was fixed already. Linux version 2.6.17-2-686 (Debian 2.6.17-9) ([EMAIL PROTECTED]) (gcc version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)) #1 SMP Wed Sep 13 16:34:10 UTC 2006 [.] ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] *enabled*) Processor #0 6:13 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] *disabled*) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) BTW, do you have a Core Duo ? If yes, do they both run ? ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] *enabled*) Processor #0 6:13 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] *disabled*) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390695: linux-image-2.6.18-1-686: weird messages upon loading the CD-ROM driver
On Tue, Oct 03, 2006 at 06:32:51PM +0200, Jens Axboe wrote: On Tue, Oct 03 2006, Oleg Verych wrote: Hallo. [Jens, let me cc you.] It's an ide core thing, not an ide-cd problem. Perhaps Alan or Bart has a good idea. OK Hilmar, 2.6.19-rc1 is out, would you like to test it, or you are not in will ? We need some more information before going further (linux-ide list, f.e), because 2.6.18 has very long cycle, and many changes are in .19 now. So, please, give it a try. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#390541: linux-image-2.6.17-2-686: 2.6.17 fails to detect PIONEER DVD-RW DVR-K15, works fine with 2.6.16
On 2006-10-02, Georg Wittenburg [EMAIL PROTECTED] wrote: Doesn't seem like it was fixed in 2.6.18 (from linux-image-2.6.18-1-686),=20 unfortunately. [EMAIL PROTECTED]:~$ egrep ide.?:|hdb dmesg-2.6.18 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=3D= xx ide0: BM-DMA at 0x1880-0x1887, BIOS settings: hda:DMA, hdb:DMA Please don't be so selfish ;), attach full bootlog (dmesg + mount output). Here i see hdb, that means device node for your drive set up. What's problem, is not clear. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#390541: linux-image-2.6.17-2-686: 2.6.17 fails to detect PIONEER DVD-RW DVR-K15, works fine with 2.6.16
On 2006-10-01, Georg Wittenburg [EMAIL PROTECTED] wrote: Package: linux-image-2.6.17-2-686 Version: 2.6.17-9 Severity: normal [-0-] Kernel 2.6.17 (from linux-image-2.6.17-2-686) fails to detect the build-in PIONEER DVD-RW DVR-K15 drive of my Sony VAIO FS295XP laptop. This worked fine with 2.6.16 (from linux-image-2.6.16-2-686) and previous kernels. Related output from dmesg looks as follows: [EMAIL PROTECTED]:~$ egrep ide.?:|hdb dmesg-2.6.1* dmesg-2.6.16:ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx dmesg-2.6.16:ide0: BM-DMA at 0x1880-0x1887, BIOS settings: hda:DMA, hdb:DMA dmesg-2.6.16:hdb: PIONEER DVD-RW DVR-K15, ATAPI CD/DVD-ROM drive dmesg-2.6.16:hdb: ATAPI 31X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(33) dmesg-2.6.17:ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx dmesg-2.6.17:ide0: BM-DMA at 0x1880-0x1887, BIOS settings: hda:DMA, hdb:DMA There isn't much output, but maybe it was fixed in 2.6.18. Try that please. This maybe related: git commit: a4f5749ba6e3f23ae4a137cee10324830db4d081, libata patch -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Probles with Core Duo processor
On 2006-10-01, Christian Schuerer [EMAIL PROTECTED] wrote: Hello Bastian, On Sunday 01 October 2006 15:20, Bastian Blank wrote: On Sun, Oct 01, 2006 at 10:49:59AM +0200, Christian Schuerer wrote: ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: 2 duplicate APIC table ignored. This is not good. The BIOS provides 3 APIC tables in the ACPI data. ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:14 APIC version 20 Local APIC of processor 0 is enabled. ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) Local APIC of processor 1 is disabled. So it can't use the CPU. thank you very much for analysing the kernel output. Sadly, I'm not a kernel/acpi/apic pro, so all I understand is that there is a problem, but I don't know what to do against it. How can I enable the local APIC of processor 1? Is there anything I can do to get things working? -+--- you also have some other problems: ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) Boot video device is :00:02.0 PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 PCI: Transparent bridge - :00:1e.0 *PCI: Bus #0a (-#0d) is hidden behind transparent bridge #09 (-#0a)* (try 'pci=assign-busses') *Please report the result to linux-kernel to fix this permanently* ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT] -+--- So, if it is another brocken ACPI BIOS, try to contact mailing-list on acpi.sf.net or try to play with DSDT as described on http://acpi.sourceforge.net/dsdt/index.php -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#390248: linux-image-2.6.18-1-686: sky2 ethernet driver crashs kernel when transfering lots of data
On 2006-09-30, Lionel Landwerlin [EMAIL PROTECTED] wrote: Subject: Bug#390248: linux-image-2.6.18-1-686: sky2 ethernet driver crashs kernel when transfering lots of data Date: Sat, 30 Sep 2006 02:04:15 +0200 Message-ID: [EMAIL PROTECTED] Archived-At: http://permalink.gmane.org/gmane.linux.debian.devel.kernel/22665 Package: linux-image-2.6.18-1-686 Version: 2.6.18-1 Severity: normal *** Please type your report below this line *** Hi, I'm using a macbook (not pro) with sky2 ethernet driver. When transfering a lot of data (divx/mp3 directory) the kernel hags. The box is completly frozen (if you're listening a mp3 file you will hear the last second of half second repeat forever), the only way to stop the box is to press the power button for 5 seconds. I cant provide a kernel backtrace, nothing is printed. There are such errors with current upsteram mm tree also: Message-ID: [EMAIL PROTECTED] http://permalink.gmane.org/gmane.linux.network/46609 (use subject link to get all thread) Maybe you can help there. -o--=O`C5 years ago TT and WTC7 were assassinated. #oo'L OLearn more why and how (tm) ___=E Mhttp://911research.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#390314: linux-image-2.6-amd64: does not boot on M2NPV-VM
On 2006-09-30, Wolfgang Lonien [EMAIL PROTECTED] wrote: Package: linux-image-2.6-amd64 Version: 2.6.17+2 Severity: normal Hi DDs, kernel 2.6.17 in the amd64 flavour still doesn't come up on my Asus M2NPV-VM, while 2.6.16 worked, as well as 2.6.17 in 32 bit. So... It's also known upstream error... Try to help there (with more debug and hardware info). Thanks. Message-Id: [EMAIL PROTECTED] http://permalink.gmane.org/gmane.linux.kernel/450972 (use subject line to get all thread) Kind regards, wjl aka Wolfgang Lonien -o--=O`C5 years ago TT and WTC7 were assassinated. #oo'L OOfficial version violates Laws of Nature. ___=E MLearn more why and how (tm) http://911research.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389232: linux-image-2.6-amd64: mounting xfs filesystem causes kernel oops
On Sun, Sep 24, 2006 at 10:19:07PM +0200, Dan Ohnesorg wrote: Dne Sun, Sep 24, 2006 at 09:23:15PM +0200, Oleg Verych napsal: Let's add XFS team in CC. There isn't Yes, my MUA... On 2006-09-24, Dan Ohnesorg [EMAIL PROTECTED] wrote: Package: linux-image-2.6-amd64 Version: 2.6.17+2 Severity: critical Justification: breaks the whole system More details, please. What happend before this boot? Why ext3 is recovering? The system was installed as 32 bit system, fresh install of debian etch, some week ago. (I remember, that beta3 of installer was only one day old). Runned good, but I have decided to migrate to 64 bit. All drives except xfs one are reformatted, only xfs has been kept untouched. Even if the xfs was probably clean unmounted, installer had some problem with mounting xfs into /target. So I deciced not to mount xfs automatically. After first boot, while mounting xfs manually the kernel oopsed and was not able to shutdown correctly, so the next boot was unclean and the ext3 (/) has to be recovered. I have made the bugreport after second unsecssful boot. The instalation was made by nightly snapshoot of installer from 24-Sep-2006 02:33. I didn't use beta3, becouse beta 3 is missing xfs libs. raid1: raid set md1 active with 4 out of 4 mirrors EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery. kjournald starting. Commit interval 5 seconds And why XFS does ? Don't know exactly, as written above. In upstream there are very hidden bugs with XFS, which are very hard to find, because they are rare and are showed on big machines: huge RAM, many CPUs. Maybe you can help. (s)ata + xfs bug: http://permalink.gmane.org/gmane.linux.kernel/446612 devmaper + xfs bug: http://permalink.gmane.org/gmane.linux.kernel/444139 The problem was solved by using my own kernel, 2.6.18. Well, that means you've cathed this (git commit): b2ea401bac39e75ebb64038609ed22efbc799905 Maybe it's worth to ask to be in next 2.6.17-stable ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)
Due to return -ENOPATCH, don't CC lkml please. Hallo, On Tue, Aug 29, 2006 at 06:30:25PM +0200, Michael Buesch wrote: On Tuesday 29 August 2006 04:15, Oleg Verych wrote: James Bottomley wrote: On Tue, 2006-08-29 at 02:35 +0200, Oleg Verych wrote: request_firmware() is dead also. YMMV, but three years, and there are still big chunks of binary in kernel. And please don't add new useless info _in_ it. I er don't think so. Hell, what can be as easy as this: ,- |modprobe $drv |(dd /lib/firmware/$drv.bin/dev/blobs echo OK) || echo Error `- where /dev/blobs is similar to /dev/port or even /dev/null char device. if synchronization is needed, add `echo $drv /dev/blobs`, remove modprobe, Please tell me how this is going to work, if we don't know which firmware (version) is needed before be actually initialize the device? be = we, right ? OK. I don't know who i'm going to explain my idea, programmer or user, but. First of all two refs: My own words: http://permalink.gmane.org/gmane.linux.kernel/435955 Just have read: http://www.sabi.co.uk/Notes/linuxPragmaCoding.html If you see my point, i'm having (system)programmers and users(admins). And this two completely opposite domains are meeting here, in a tiny task as firmware uploading. Situation even harder: kernel developers mainly are not bare-metal or firmware system programmers. So. You are seeing chardev-like interface to kernel, and asking how this is suppose to work ? Remember that ACPI description from mr. Linus ? Yes, As a someone who's spent a lot if his life doing contract/consulting work, I've spent a lot of time breaking the bad habits of the junior programmers assigned to work with me on various jobs. The most valuable lesson I was ever able to teach them is that when you uncover a problem, see if the design needs fixing before you barge in and start trying to fix the code. -- rbsjrx [EMAIL PROTECTED] That interface is for main etab-library (external text and binary or external tab (with LSD ;)) of all kinds of hardware config. stuff: USB id, PCI id, CPU microcode, GPU microcode, all kinds of firmwares. This etab-library is a simple list of * driver-name * acquired-ext-config items. When driver is registered (module or in-kernel) it places an order for etab, what it needs. Admin(user) knowing its hardware (hotplug or not) compose a directory of etab-files with all info for every driver-name. Note, that linux isn't a microkernel, and adding whatever feature in running kernel isn't possible without patch/config/make. And all this is mostly done by distributions, isn't it ? Thus we have all info admin wants and kernel(drivers) needs. Bounds, sizes, lifetimes of in-kernel etabs is a set, to workout. Unless you need all this on boot time, use chardev-like interface, otherwise use kernel loader, by adding cpio-etab image to initrd= bootloader option ([1] monolithic kernel), or initramfs (initrd fs) + chardev in case of moduled one [2], [3] usage is what you've saw in my prev. message. Then, let me take your example: The ipw needs the firmware on insmod time [1], [2], [3] (in contrast to bcm43xx for example, which needs it on ifconfig up time). [1], [2], [3] Handling orders, etab-library itself is an internal part, like /dev/zero or /dev/null. Implementation seems small and obvious... Your thoughts ? -- -o--=O`C /. .\ (+) #oo'L O o| ___=E M^--| (you're barking up the wrong tree) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)
Sven Luther wrote: On Mon, Aug 28, 2006 at 05:11:42PM -0500, James Bottomley wrote: I've tested this with the aic94xx driver using the new MODULE_FIRMWARE() tag. Initramfs should be much easier because it already includes most of the boot time loading; all it has to do is the piece identifying the firmware for the selected modules. Notice that mkinitrd-tools is dead, and will probably be removed from etch. request_firmware() is dead also. YMMV, but three years, and there are still big chunks of binary in kernel. And please don't add new useless info _in_ it. Nobody cares. While this implementation exists, it wasn't well designed and hard to use. As with in-kernel bootsplash and i18n, everything maybe done in userspace, only with little help from the kernel: http://permalink.gmane.org/gmane.linux.kernel/435955. Thanks. -- -o--=O`C /. .\ (+) #oo'L O o| ___=E M^--| (you're barking up the wrong tree) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)
James Bottomley wrote: On Tue, 2006-08-29 at 02:35 +0200, Oleg Verych wrote: request_firmware() is dead also. YMMV, but three years, and there are still big chunks of binary in kernel. And please don't add new useless info _in_ it. I er don't think so. Hell, what can be as easy as this: ,- |modprobe $drv |(dd /lib/firmware/$drv.bin/dev/blobs echo OK) || echo Error `- where /dev/blobs is similar to /dev/port or even /dev/null char device. if synchronization is needed, add `echo $drv /dev/blobs`, remove modprobe, James ? -- -- -o--=O`C /. .\ (+) #oo'L O o| ___=E M^--| (you're barking up the wrong tree) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)
On Mon, Aug 28, 2006 at 06:51:03PM -0700, Greg KH wrote: On Tue, Aug 29, 2006 at 04:15:49AM +0200, Oleg Verych wrote: request_firmware() is dead also. YMMV, but three years, and there are still big chunks of binary in kernel. And please don't add new useless info _in_ it. Hell, what can be as easy as this: ,- |modprobe $drv |(dd /lib/firmware/$drv.bin/dev/blobs echo OK) || echo Error `- where /dev/blobs is similar to /dev/port or even /dev/null char device. if synchronization is needed, add `echo $drv /dev/blobs`, remove modprobe, I don't see such code in the kernel at this time. So it's not a solution, sorry. I know. return -ENOPATCH No amount of clever coding can ever make up for a poor design. Conversely, a well-architected system can tolerate a lot of sloppy coding. In a society where organizations are increasingly filled with more inexperienced workers whose salaries don't frag down the bottom line, you have to expect some sloppy coding, so the design becomes even more important. -- rbsjrx [EMAIL PROTECTED] I'm nether a CS nor software engineer, just wondering why simple thing isn't simple _in_ the Kernel. I'm reading list just for fun (C) and any good word about this (IMHO) unix-way design *may* lead professional programmers to do tiny worthy things (think about kevent discussion). If it's (i'm) stupid, please, say so (in the way Nicholas Miell did ;). Thanks. -- -o--=O`C /. .\ (+) #oo'L O o| ___=E M^--| (you're barking up the wrong tree) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)
Greg KH wrote: On Tue, Aug 29, 2006 at 05:14:30AM +0200, Oleg Verych wrote: On Mon, Aug 28, 2006 at 06:51:03PM -0700, Greg KH wrote: On Tue, Aug 29, 2006 at 04:15:49AM +0200, Oleg Verych wrote: request_firmware() is dead also. YMMV, but three years, and there are still big chunks of binary in kernel. And please don't add new useless info _in_ it. Hell, what can be as easy as this: ,- |modprobe $drv |(dd /lib/firmware/$drv.bin/dev/blobs echo OK) || echo Error `- where /dev/blobs is similar to /dev/port or even /dev/null char device. if synchronization is needed, add `echo $drv /dev/blobs`, remove modprobe, ... I'm nether a CS nor software engineer, just wondering why simple thing isn't simple _in_ the Kernel. I'm reading list just for fun (C) and any good word about this (IMHO) unix-way design *may* lead professional programmers to do tiny worthy things (think about kevent discussion). If it's (i'm) stupid, please, say so (in the way Nicholas Miell did ;). I don't think it's workable, and goes against the current way the kernel does things. But please, feel free to prove me wrong with a patch otherwise. I don't want to debate it otherwise. Thanks, and OK, this is my last reply on this. I think the current way we handle firmware works quite well, especially given the wide range of different devices that it works for (everything from BIOS upgrades to different wireless driver stages). Oh, come on, even skilled developers (not particular kernel's) having difficulties with current hotplug-sysfs-modprobe thing; in this case one couldn't easily figure out problems and way to solve them http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/5444 Goodbye. -- -o--=O`C /. .\ (+) #oo'L O o| ___=E M^--| (you're barking up the wrong tree) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
