From acro3451 at tss.com.ar Tue Jan 1 19:48:00 2008 From: acro3451 at tss.com.ar (Pls check this new site) Date: Tue, 1 Jan 2008 14:48 -0500 Subject: www.locucionintegral.com.ar Message-ID: <200801011955.m01JtWed000346@mx3.redhat.com> Please see this site in Subject -------------- next part -------------- An HTML attachment was scrubbed... URL: From romal at gmx.de Tue Jan 1 23:09:21 2008 From: romal at gmx.de (Robert M. Albrecht) Date: Wed, 02 Jan 2008 00:09:21 +0100 Subject: Problems compiling kernel on rawhide Message-ID: <477AC821.1040901@gmx.de> Hi, I tried to compile a kernel (to test a patched driver). I installed the srpm, did an rpmbuild, ... all works. After installing and booting the new kernel the systems hangs with setuproot: /moving dev failed: No such efil or directory setuproot: error mounting /proc setuproot: error mounting /sys switchroot: mount failed ... I think the systems does not load the storag-drivers (at least I don`t find their messages). The initrd is found and loaded, should the kernel have the drivers here ? cu romal From eparis at redhat.com Wed Jan 2 02:38:50 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 01 Jan 2008 21:38:50 -0500 Subject: Problems compiling kernel on rawhide In-Reply-To: <477AC821.1040901@gmx.de> References: <477AC821.1040901@gmx.de> Message-ID: <1199241530.3716.15.camel@localhost.localdomain> On Wed, 2008-01-02 at 00:09 +0100, Robert M. Albrecht wrote: > Hi, > > I tried to compile a kernel (to test a patched driver). > > I installed the srpm, did an rpmbuild, ... all works. > > After installing and booting the new kernel the systems hangs with > > setuproot: /moving dev failed: No such efil or directory > setuproot: error mounting /proc > setuproot: error mounting /sys > switchroot: mount failed ... > > I think the systems does not load the storag-drivers (at least I don`t > find their messages). The initrd is found and loaded, should the kernel > have the drivers here ? > > cu romal I'd probably retry running mkinitrd by hand, I believe it will give you decent error messages if the drivers aren't built/installed correctly (assuming /etc/modprobe.conf is correct....) man 8 mkinitrd -Eric > > _______________________________________________ > Fedora-kernel-list mailing list > Fedora-kernel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-kernel-list From acro3451 at tss.com.ar Wed Jan 2 05:51:00 2008 From: acro3451 at tss.com.ar (Pls check this new site) Date: Wed, 2 Jan 2008 00:51 -0500 Subject: www.chequesonline.com.ar Message-ID: <200801020618.m026IDav032220@mx3.redhat.com> Please see this site in Subject -------------- next part -------------- An HTML attachment was scrubbed... URL: From romal at gmx.de Wed Jan 2 08:35:33 2008 From: romal at gmx.de (Robert M. Albrecht) Date: Wed, 02 Jan 2008 09:35:33 +0100 Subject: Problems compiling kernel on rawhide In-Reply-To: <1199241530.3716.15.camel@localhost.localdomain> References: <477AC821.1040901@gmx.de> <1199241530.3716.15.camel@localhost.localdomain> Message-ID: <477B4CD5.2010502@gmx.de> Hi, I did it manually, no message at all, but the file is generated. Should this be generated automatic ? [root at helios ~]# mkinitrd -f /boot/initrd-2.6.24-rc3-git7-ahci.img 2.6.24-rc3-git7-ahci [root at helios ~]# cat /etc/modprobe.conf alias snd-card-0 snd-hda-intel options snd-card-0 index=0 options snd-hda-intel index=0 alias eth0 sky2 [root at helios ~]# [root at helios ~]# ll /boot/initrd-2.6.24-* -rw------- 1 root root 2472631 4. Dez 08:32 /boot/initrd-2.6.24-0.66.rc3.git7.fc9.img -rw------- 1 root root 2319134 2. Jan 09:34 /boot/initrd-2.6.24-rc3-git7-ahci.img [root at helios ~]# cu romal Eric Paris schrieb: > On Wed, 2008-01-02 at 00:09 +0100, Robert M. Albrecht wrote: >> Hi, >> >> I tried to compile a kernel (to test a patched driver). >> >> I installed the srpm, did an rpmbuild, ... all works. >> >> After installing and booting the new kernel the systems hangs with >> >> setuproot: /moving dev failed: No such efil or directory >> setuproot: error mounting /proc >> setuproot: error mounting /sys >> switchroot: mount failed ... >> >> I think the systems does not load the storag-drivers (at least I don`t >> find their messages). The initrd is found and loaded, should the kernel >> have the drivers here ? >> >> cu romal > > I'd probably retry running mkinitrd by hand, I believe it will give you > decent error messages if the drivers aren't built/installed correctly > (assuming /etc/modprobe.conf is correct....) > > man 8 mkinitrd > > -Eric > > >> _______________________________________________ >> Fedora-kernel-list mailing list >> Fedora-kernel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-kernel-list From cmurnane at restarea.ncsc.mil Wed Jan 2 10:35:53 2008 From: cmurnane at restarea.ncsc.mil (Chuck Murnane) Date: Wed, 02 Jan 2008 05:35:53 -0500 Subject: Do recent kernels allow firmware to load at initrd time? Message-ID: <477B6909.4060203@restarea.ncsc.mil> Sorry for the delay in responding: I was off for the holidays. As mentioned in bug 378651, it the new mkinitrd also solves my problem. Thank you. Chuck Murnane From romal at gmx.de Wed Jan 2 10:45:01 2008 From: romal at gmx.de (Robert M. Albrecht) Date: Wed, 02 Jan 2008 11:45:01 +0100 Subject: Problems compiling kernel on rawhide In-Reply-To: <477B4CD5.2010502@gmx.de> References: <477AC821.1040901@gmx.de> <1199241530.3716.15.camel@localhost.localdomain> <477B4CD5.2010502@gmx.de> Message-ID: <477B6B2D.3020309@gmx.de> Hi, I updated to rawhides kernel 123 (yum update kernel) and got the same problem. Is this a general problem with buildung kernels ? cu romal Robert M. Albrecht schrieb: > Hi, > > I did it manually, no message at all, but the file is generated. Should > this be generated automatic ? > > [root at helios ~]# mkinitrd -f /boot/initrd-2.6.24-rc3-git7-ahci.img > 2.6.24-rc3-git7-ahci > > [root at helios ~]# cat /etc/modprobe.conf > alias snd-card-0 snd-hda-intel > options snd-card-0 index=0 > options snd-hda-intel index=0 > alias eth0 sky2 > [root at helios ~]# > > [root at helios ~]# ll /boot/initrd-2.6.24-* > -rw------- 1 root root 2472631 4. Dez 08:32 > /boot/initrd-2.6.24-0.66.rc3.git7.fc9.img > -rw------- 1 root root 2319134 2. Jan 09:34 > /boot/initrd-2.6.24-rc3-git7-ahci.img > [root at helios ~]# > > > cu romal > > > Eric Paris schrieb: >> On Wed, 2008-01-02 at 00:09 +0100, Robert M. Albrecht wrote: >>> Hi, >>> >>> I tried to compile a kernel (to test a patched driver). >>> >>> I installed the srpm, did an rpmbuild, ... all works. >>> >>> After installing and booting the new kernel the systems hangs with >>> >>> setuproot: /moving dev failed: No such efil or directory >>> setuproot: error mounting /proc >>> setuproot: error mounting /sys >>> switchroot: mount failed ... >>> >>> I think the systems does not load the storag-drivers (at least I don`t >>> find their messages). The initrd is found and loaded, should the kernel >>> have the drivers here ? >>> >>> cu romal >> >> I'd probably retry running mkinitrd by hand, I believe it will give you >> decent error messages if the drivers aren't built/installed correctly >> (assuming /etc/modprobe.conf is correct....) >> >> man 8 mkinitrd >> >> -Eric >> >> >>> _______________________________________________ >>> Fedora-kernel-list mailing list >>> Fedora-kernel-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-kernel-list > > _______________________________________________ > Fedora-kernel-list mailing list > Fedora-kernel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-kernel-list From acro3451 at tss.com.ar Wed Jan 2 13:05:00 2008 From: acro3451 at tss.com.ar (Pls check this new site) Date: Wed, 2 Jan 2008 08:05 -0500 Subject: www.juniorguide.com Message-ID: <200801021333.m02DXtWX001294@mx3.redhat.com> Please see this site in Subject -------------- next part -------------- An HTML attachment was scrubbed... URL: From eparis at redhat.com Wed Jan 2 19:20:09 2008 From: eparis at redhat.com (Eric Paris) Date: Wed, 02 Jan 2008 14:20:09 -0500 Subject: Problems compiling kernel on rawhide In-Reply-To: <477B4CD5.2010502@gmx.de> References: <477AC821.1040901@gmx.de> <1199241530.3716.15.camel@localhost.localdomain> <477B4CD5.2010502@gmx.de> Message-ID: <1199301609.3716.24.camel@localhost.localdomain> On Wed, 2008-01-02 at 09:35 +0100, Robert M. Albrecht wrote: > Hi, > > I did it manually, no message at all, but the file is generated. Should > this be generated automatic ? > > [root at helios ~]# mkinitrd -f /boot/initrd-2.6.24-rc3-git7-ahci.img > 2.6.24-rc3-git7-ahci > > [root at helios ~]# cat /etc/modprobe.conf > alias snd-card-0 snd-hda-intel > options snd-card-0 index=0 > options snd-hda-intel index=0 > alias eth0 sky2 > [root at helios ~]# odd, there should be some lines in there for your storage driver, I have: alias scsi_hostadapter libata alias scsi_hostadapter1 ata_piix there is probably some sort of kudzu magic that could be used to generate that, or you can figure out which drivers you need and add them in by hand. Then rebuilt the initrd and try again.... -Eric From acro3451 at tss.com.ar Wed Jan 2 19:02:00 2008 From: acro3451 at tss.com.ar (Pls check this new site) Date: Wed, 2 Jan 2008 14:02 -0500 Subject: www.perdidacabello.com.ar Message-ID: <200801022003.m02K3DvO028101@mx3.redhat.com> Please see this site in Subject -------------- next part -------------- An HTML attachment was scrubbed... URL: From romal at gmx.de Wed Jan 2 20:32:50 2008 From: romal at gmx.de (Robert M. Albrecht) Date: Wed, 02 Jan 2008 21:32:50 +0100 Subject: Problems compiling kernel on rawhide In-Reply-To: <1199301609.3716.24.camel@localhost.localdomain> References: <477AC821.1040901@gmx.de> <1199241530.3716.15.camel@localhost.localdomain> <477B4CD5.2010502@gmx.de> <1199301609.3716.24.camel@localhost.localdomain> Message-ID: <477BF4F2.1010704@gmx.de> Hi, indeed, this helps. I added the drivers plus ahci to modprobe.conf and generated a new initrd and the systems boots. Thanks. cu romal Eric Paris schrieb: > On Wed, 2008-01-02 at 09:35 +0100, Robert M. Albrecht wrote: >> Hi, >> >> I did it manually, no message at all, but the file is generated. Should >> this be generated automatic ? >> >> [root at helios ~]# mkinitrd -f /boot/initrd-2.6.24-rc3-git7-ahci.img >> 2.6.24-rc3-git7-ahci >> >> [root at helios ~]# cat /etc/modprobe.conf >> alias snd-card-0 snd-hda-intel >> options snd-card-0 index=0 >> options snd-hda-intel index=0 >> alias eth0 sky2 >> [root at helios ~]# > > odd, there should be some lines in there for your storage driver, I > have: > > alias scsi_hostadapter libata > alias scsi_hostadapter1 ata_piix > > there is probably some sort of kudzu magic that could be used to > generate that, or you can figure out which drivers you need and add them > in by hand. Then rebuilt the initrd and try again.... > > -Eric From david at fubar.dk Thu Jan 3 18:34:43 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 03 Jan 2008 13:34:43 -0500 Subject: kernels won't boot In-Reply-To: <200712220828.48202.sgrubb@redhat.com> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> Message-ID: <1199385283.2850.1.camel@oneill.fubar.dk> On Sat, 2007-12-22 at 08:28 -0500, Steve Grubb wrote: > On Saturday 22 December 2007 07:16:32 Build System wrote: > > kernel-2.6.24-0.123.rc6.fc9 > > --------------------------- > > * Fri Dec 21 2007 David Woodhouse > > - Disable CONFIG_PS3_USE_LPAR_ADDR to fix PS3 memory probing > > > > * Fri Dec 21 2007 John W. Linville > > - Yet another round of wireless updates... > > > > * Thu Dec 20 2007 Kyle McMartin > > - 2.6.24-rc6 > > > After build 81, I have not been able to boot any of the x86_64 rawhide > kernels. They all end with: > > Trying to resume from /sys/block/sda/sda3 > Unable to access resume device (/sys/block/sda/sda3) > Creating root device > Mounting root filesystem > mount: could not find '/dev/root' > Setting up other filesystems > Setting up new root fs > setuproot: moving /dev failed: No such file or directory > no fstab.sys, mounting internal defaults > setuproot: error mounting /proc: No such file or directory > setuproot: error mounting /sys: No such file or directory > Switching to new root and running init > unmounting old /dev > unmounting old /proc > unmounting old /sys > switchroot: mount failed: No such file or directory > Booting has failed. > > Rebooting into trusty old 2.6.24-0.81.rc4.git7.fc9 works fine. Are other > people running into this? I'm still seeing this too on all my x86 and x86_64 boxes with all kernels including todays update. Peter, Dave, any clue? David From pjones at redhat.com Thu Jan 3 19:03:20 2008 From: pjones at redhat.com (Peter Jones) Date: Thu, 03 Jan 2008 14:03:20 -0500 Subject: kernels won't boot In-Reply-To: <1199385283.2850.1.camel@oneill.fubar.dk> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> Message-ID: <477D3178.9020108@redhat.com> David Zeuthen wrote: > On Sat, 2007-12-22 at 08:28 -0500, Steve Grubb wrote: >> On Saturday 22 December 2007 07:16:32 Build System wrote: >>> kernel-2.6.24-0.123.rc6.fc9 >>> --------------------------- >>> * Fri Dec 21 2007 David Woodhouse >>> - Disable CONFIG_PS3_USE_LPAR_ADDR to fix PS3 memory probing >>> >>> * Fri Dec 21 2007 John W. Linville >>> - Yet another round of wireless updates... >>> >>> * Thu Dec 20 2007 Kyle McMartin >>> - 2.6.24-rc6 >> >> After build 81, I have not been able to boot any of the x86_64 rawhide >> kernels. They all end with: >> >> Trying to resume from /sys/block/sda/sda3 >> Unable to access resume device (/sys/block/sda/sda3) >> Creating root device >> Mounting root filesystem >> mount: could not find '/dev/root' >> Setting up other filesystems >> Setting up new root fs >> setuproot: moving /dev failed: No such file or directory >> no fstab.sys, mounting internal defaults >> setuproot: error mounting /proc: No such file or directory >> setuproot: error mounting /sys: No such file or directory >> Switching to new root and running init >> unmounting old /dev >> unmounting old /proc >> unmounting old /sys >> switchroot: mount failed: No such file or directory >> Booting has failed. >> >> Rebooting into trusty old 2.6.24-0.81.rc4.git7.fc9 works fine. Are other >> people running into this? > > I'm still seeing this too on all my x86 and x86_64 boxes with all > kernels including todays update. > > Peter, Dave, any clue? Can you show me more of the log? -- Peter From eparis at redhat.com Thu Jan 3 19:08:13 2008 From: eparis at redhat.com (Eric Paris) Date: Thu, 03 Jan 2008 14:08:13 -0500 Subject: kernels won't boot In-Reply-To: <477D3178.9020108@redhat.com> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> Message-ID: <1199387293.3716.39.camel@localhost.localdomain> On Thu, 2008-01-03 at 14:03 -0500, Peter Jones wrote: > David Zeuthen wrote: > > On Sat, 2007-12-22 at 08:28 -0500, Steve Grubb wrote: > >> On Saturday 22 December 2007 07:16:32 Build System wrote: > >>> kernel-2.6.24-0.123.rc6.fc9 > >>> --------------------------- > >>> * Fri Dec 21 2007 David Woodhouse > >>> - Disable CONFIG_PS3_USE_LPAR_ADDR to fix PS3 memory probing > >>> > >>> * Fri Dec 21 2007 John W. Linville > >>> - Yet another round of wireless updates... > >>> > >>> * Thu Dec 20 2007 Kyle McMartin > >>> - 2.6.24-rc6 > >> > >> After build 81, I have not been able to boot any of the x86_64 rawhide > >> kernels. They all end with: > >> > >> Trying to resume from /sys/block/sda/sda3 > >> Unable to access resume device (/sys/block/sda/sda3) > >> Creating root device > >> Mounting root filesystem > >> mount: could not find '/dev/root' > >> Setting up other filesystems > >> Setting up new root fs > >> setuproot: moving /dev failed: No such file or directory > >> no fstab.sys, mounting internal defaults > >> setuproot: error mounting /proc: No such file or directory > >> setuproot: error mounting /sys: No such file or directory > >> Switching to new root and running init > >> unmounting old /dev > >> unmounting old /proc > >> unmounting old /sys > >> switchroot: mount failed: No such file or directory > >> Booting has failed. > >> > >> Rebooting into trusty old 2.6.24-0.81.rc4.git7.fc9 works fine. Are other > >> people running into this? > > > > I'm still seeing this too on all my x86 and x86_64 boxes with all > > kernels including todays update. > > > > Peter, Dave, any clue? > > Can you show me more of the log? > I think selinux-policy is busted at the moment. depmod and mkinitrd are having trouble in enforcing... rpm -e kernel-2.6.24-133-blah-blah setenforce 0 yum update kernel setenforce 1 if that fixes it blame selinux Also get the same result if you don't have your storage driver in /etc/modprobe.conf so you can look there first... -Eric From david at fubar.dk Thu Jan 3 19:09:06 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 03 Jan 2008 14:09:06 -0500 Subject: kernels won't boot In-Reply-To: <1199387293.3716.39.camel@localhost.localdomain> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> Message-ID: <1199387346.2850.24.camel@oneill.fubar.dk> On Thu, 2008-01-03 at 14:08 -0500, Eric Paris wrote: > > Can you show me more of the log? > > The log is more sgrubb. > I think selinux-policy is busted at the moment. depmod and mkinitrd are > having trouble in enforcing... > > rpm -e kernel-2.6.24-133-blah-blah > setenforce 0 > yum update kernel > setenforce 1 > > if that fixes it blame selinux > > Also get the same result if you don't have your storage driver > in /etc/modprobe.conf so you can look there first... I'm not running SELinux enforcing mode on any of my machines.. David From davidz at redhat.com Thu Jan 3 19:10:20 2008 From: davidz at redhat.com (David Zeuthen) Date: Thu, 03 Jan 2008 14:10:20 -0500 Subject: kernels won't boot In-Reply-To: <1199387346.2850.24.camel@oneill.fubar.dk> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> <1199387346.2850.24.camel@oneill.fubar.dk> Message-ID: <1199387420.2850.26.camel@oneill.fubar.dk> On Thu, 2008-01-03 at 14:09 -0500, David Zeuthen wrote: > On Thu, 2008-01-03 at 14:08 -0500, Eric Paris wrote: > > > Can you show me more of the log? > > > > > The log is more sgrubb. Eh.. From.. the log is from sgrubb. That's what I meant. David From davidz at redhat.com Thu Jan 3 20:23:10 2008 From: davidz at redhat.com (David Zeuthen) Date: Thu, 03 Jan 2008 15:23:10 -0500 Subject: kernels won't boot In-Reply-To: <1199387420.2850.26.camel@oneill.fubar.dk> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> <1199387346.2850.24.camel@oneill.fubar.dk> <1199387420.2850.26.camel@oneill.fubar.dk> Message-ID: <1199391790.10354.0.camel@oneill.fubar.dk> Hi, We're now tracking this issue in ? https://bugzilla.redhat.com/show_bug.cgi?id=427439 David From sgrubb at redhat.com Thu Jan 3 20:38:16 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 3 Jan 2008 15:38:16 -0500 Subject: kernels won't boot In-Reply-To: <1199387420.2850.26.camel@oneill.fubar.dk> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <1199387346.2850.24.camel@oneill.fubar.dk> <1199387420.2850.26.camel@oneill.fubar.dk> Message-ID: <200801031538.17043.sgrubb@redhat.com> On Thursday 03 January 2008 14:10:20 David Zeuthen wrote: > > > > Can you show me more of the log? > > > > The log is more sgrubb. > > Eh.. From.. the log is from sgrubb. That's what I meant. Turns out the problem shows up on my laptop. I started to hook up a serial cable and found doesn't have a serial port. I thought it did...so no logs. -Steve From j.w.r.degoede at hhs.nl Thu Jan 3 22:53:35 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 03 Jan 2008 23:53:35 +0100 Subject: Kernel fudcon hackfests Message-ID: <477D676F.8050202@hhs.nl> Hi All, Unfortunately I cannot be physically present at the kernel fudcon hackfests, but I would still like to try and help, any chance we can have some electronic interaction, for example somewhere on freenode? Regards, Hans From editora at cerebroecomunicacao.com.br Fri Jan 4 00:45:14 2008 From: editora at cerebroecomunicacao.com.br (Cérebro & Comunicação - Desenvolvimento Pessoal) Date: Fri, 4 Jan 2008 00:45:14 GMT Subject: agenda de cursos atualizada: janeiro / fevereiro 2008. Message-ID: <200801041824.m04IOUnv029301@mx3.redhat.com> An HTML attachment was scrubbed... URL: From justinkoku at rediffmail.com Fri Jan 4 19:54:18 2008 From: justinkoku at rediffmail.com (justin koku) Date: Fri, 04 Jan 2008 13:54:18 -0600 Subject: trace of heirs Message-ID: Dear Business Partner, My name is JUSTIN KOKU , the Chairman of Independent Committee on Unclaimed Foreign Funds (I.C.U.F.F),Senegal ICUFF is charged with the responsibility of finding foreign bank accounts abroad belonging to our late citizens which have remained dormant/unclaimed over the years.It may interest you to know that In 2004, A list of dormant accounts originally owned by our citizens was and sent to our country's government.Some of these dormant accounts belonged to our late citizens of Senegal. The continuing efforts of the Independent Committee on Unclaimed Foreign Funds (I.C.U.F.F) has since resulted in the discovery of additional dormant accounts,securities accounts, safe deposit boxes, custody accounts,non interest bearing accounts. A routine notification has been sent from a security firm abroad to my office to make available the beneficiary for the claim of US$12.5 million belonging to one of our late citizens . The depositor died several years back leaving no possible records for trace of heirs. I need a foreign partner to ASSIST claim this deposit as the beneficiary.You will be required to provide me with your details for the processing of the necessary legal, and administrative claim documents or your claim in the Security company abroad.Provide me with your full name,address, and telephone/fax. SEEING IS BELIEVING.THERE IS NO RISK INVOLVED.YOUR MAXIMUM COOPERATION NEEDED. I am pledging to give you some percentage of the total value of the said deposit for your assistance . I want you to immediately contact me and I will furnish you with more information about the process of transfer to you. Thank you for your prompt response. JUSTIN KOKU . N.B:Please respond with your full names, address, phone and fax numbers for the immediate start up of this transaction. Do note that who you are does not matter and you will be better informed when I hear from you. From raven at themaw.net Sun Jan 6 15:43:59 2008 From: raven at themaw.net (Ian Kent) Date: Mon, 07 Jan 2008 00:43:59 +0900 Subject: Proceedure for package private branches for testing In-Reply-To: <1199630579.4111.342.camel@shinybook.infradead.org> References: <1199616844.3434.7.camel@raven.themaw.net> <200801061309.43329.opensource@till.name> <1199621949.6782.7.camel@raven.themaw.net> <1199630579.4111.342.camel@shinybook.infradead.org> Message-ID: <1199634239.3526.7.camel@raven.themaw.net> On Sun, 2008-01-06 at 14:42 +0000, David Woodhouse wrote: > On Sun, 2008-01-06 at 21:19 +0900, Ian Kent wrote: > > Yes, I got this advice on IRC and managed to get a build. > > You seemed to say something really bizarre on IRC -- that local builds > of the kernel rarely worked. Can you elucidate? I find that for some reason or another source rpm kernel builds fail for me a lot on my local machine. The last couple of times I've tried I've been getting an error about debugedit -b option and incorrect argument lengths. I tried to work out what the problem was last time I got it without success. Anyway, over the years, I've ended up with the feeling that kernel builds from standard Fedora source packages often don't work for me. But that may be a little hash as I always seem to have a problem when I can least afford it. Ian From roland at redhat.com Mon Jan 7 01:19:36 2008 From: roland at redhat.com (Roland McGrath) Date: Sun, 6 Jan 2008 17:19:36 -0800 (PST) Subject: utrace Message-ID: <20080107011937.1C6C026F9A4@magilla.localdomain> I may have hashed this out with davej only in private before, so perhaps you aren't aware of the normal plan for utrace updates. You disabled utrace when you should have just run ./scripts/pull-upstreams.sh to get the current patch set. The 2008-1-3 version of the patches already applied fine. (I just regenerated for 2.6.24-rc7 but there were in fact zero changes to the patch files vs the files already up on 2008-1-3.) Thanks, Roland From kyle at mcmartin.ca Mon Jan 7 01:54:13 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Sun, 6 Jan 2008 20:54:13 -0500 Subject: utrace In-Reply-To: <20080107011937.1C6C026F9A4@magilla.localdomain> References: <20080107011937.1C6C026F9A4@magilla.localdomain> Message-ID: <20080107015413.GA27747@fattire.cabal.ca> On Sun, Jan 06, 2008 at 05:19:36PM -0800, Roland McGrath wrote: > I may have hashed this out with davej only in private before, so perhaps > you aren't aware of the normal plan for utrace updates. You disabled > utrace when you should have just run ./scripts/pull-upstreams.sh to get the > current patch set. The 2008-1-3 version of the patches already applied > fine. (I just regenerated for 2.6.24-rc7 but there were in fact zero > changes to the patch files vs the files already up on 2008-1-3.) > Doh, I checked your people.redhat.com page, but only checked the top level (utrace/ 14-Dec-2007 21:45 -) and assumed you hadn't updated the patches yet. Will know better in the future. cheers, Kyle From jwboyer at gmail.com Mon Jan 7 04:36:39 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sun, 6 Jan 2008 22:36:39 -0600 Subject: utrace In-Reply-To: <20080107011937.1C6C026F9A4@magilla.localdomain> References: <20080107011937.1C6C026F9A4@magilla.localdomain> Message-ID: <20080106223639.7eecc558@vader.jdub.homelinux.org> On Sun, 6 Jan 2008 17:19:36 -0800 (PST) Roland McGrath wrote: > I may have hashed this out with davej only in private before, so perhaps > you aren't aware of the normal plan for utrace updates. You disabled > utrace when you should have just run ./scripts/pull-upstreams.sh to get the > current patch set. The 2008-1-3 version of the patches already applied > fine. (I just regenerated for 2.6.24-rc7 but there were in fact zero > changes to the patch files vs the files already up on 2008-1-3.) utrace is what again? A ptrace rewrite/replacement? josh From nayankumarp at hotmail.com Tue Jan 8 05:33:52 2008 From: nayankumarp at hotmail.com (nayan kumar) Date: Tue, 8 Jan 2008 11:03:52 +0530 Subject: How to remove this warning Message-ID: Hi All, I am trying to make stack for my learning in which i made a bus driver and device driver when i am trying to create device sysfs file after registering it with the bus i am getting oops after some digging i found that the compiler is reporting warning for using preprocessor macro called DEV_ATT. code is as follows. can anybody help me to remove this warning. static ssize_t show_host_device_version(struct device *ddev, char *buf){ struct HOST *dev = ddev->driver_data; return print_dev_t(buf, dev->cdev.dev);}static DEVICE_ATTR(host_device_version,S_IRUGO,show_host_device_version,NULL); device_create_file(&dev->host.dev, &dev_attr_host_device_version); Regards _________________________________________________________________ Post ads for free - to sell, rent or even buy.www.yello.in http://ss1.richmedia.in/recurl.asp?pid=186 -------------- next part -------------- An HTML attachment was scrubbed... URL: From markg85 at gmail.com Tue Jan 8 14:30:39 2008 From: markg85 at gmail.com (Mark) Date: Tue, 8 Jan 2008 15:30:39 +0100 Subject: UVESAFB in kernel 2.6.24 Message-ID: <6e24a8e80801080630id46272fq28e0cd30ae724d39@mail.gmail.com> Hey, I just downloaded and installed the latest kernel rpm from koji [1] but found out that uvesafb isn't enabled in the fedora kernels. Could a kernel maintainer put the following value in the config-generc: CONFIG_FB_UVESA=y so that uvesafb is enabled in the next build? more information about uvesafb can be found here [2]. Thanx, Mark [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=30342 [2] http://dev.gentoo.org/~spock/projects/uvesafb/ From notting at redhat.com Tue Jan 8 16:51:46 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 8 Jan 2008 11:51:46 -0500 Subject: UVESAFB in kernel 2.6.24 In-Reply-To: <6e24a8e80801080630id46272fq28e0cd30ae724d39@mail.gmail.com> References: <6e24a8e80801080630id46272fq28e0cd30ae724d39@mail.gmail.com> Message-ID: <20080108165146.GA2792@nostromo.devel.redhat.com> Mark (markg85 at gmail.com) said: > Hey, > > I just downloaded and installed the latest kernel rpm from koji [1] > but found out that uvesafb isn't enabled in the fedora kernels. Could > a kernel maintainer put the following value in the config-generc: > > CONFIG_FB_UVESA=y > > so that uvesafb is enabled in the next build? > more information about uvesafb can be found here [2]. Why wouldn't it be a module like (most) other framebuffers? Bill From markg85 at gmail.com Tue Jan 8 16:57:33 2008 From: markg85 at gmail.com (Mark) Date: Tue, 8 Jan 2008 17:57:33 +0100 Subject: UVESAFB in kernel 2.6.24 In-Reply-To: <20080108165146.GA2792@nostromo.devel.redhat.com> References: <6e24a8e80801080630id46272fq28e0cd30ae724d39@mail.gmail.com> <20080108165146.GA2792@nostromo.devel.redhat.com> Message-ID: <6e24a8e80801080857s1d19157bo5c43c46ce09e65e0@mail.gmail.com> 2008/1/8, Bill Nottingham : > Mark (markg85 at gmail.com) said: > > Hey, > > > > I just downloaded and installed the latest kernel rpm from koji [1] > > but found out that uvesafb isn't enabled in the fedora kernels. Could > > a kernel maintainer put the following value in the config-generc: > > > > CONFIG_FB_UVESA=y > > > > so that uvesafb is enabled in the next build? > > more information about uvesafb can be found here [2]. > > Why wouldn't it be a module like (most) other framebuffers? > > Bill Well.. vesafb is also enabled with 'y' and because uvesafb is it's successor it seems logical to me that it also gets enabled with 'y' (not as a module but build in). Perhaps a good idea for fedora to add a anaconda installer option that allows you to set the boot resolution or add the option in the firstboot. From cebbert at redhat.com Tue Jan 8 16:59:11 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 08 Jan 2008 11:59:11 -0500 Subject: UVESAFB in kernel 2.6.24 In-Reply-To: <6e24a8e80801080630id46272fq28e0cd30ae724d39@mail.gmail.com> References: <6e24a8e80801080630id46272fq28e0cd30ae724d39@mail.gmail.com> Message-ID: <4783ABDF.8010609@redhat.com> On 01/08/2008 09:30 AM, Mark wrote: > Hey, > > I just downloaded and installed the latest kernel rpm from koji [1] > but found out that uvesafb isn't enabled in the fedora kernels. Could > a kernel maintainer put the following value in the config-generc: > > CONFIG_FB_UVESA=y > > so that uvesafb is enabled in the next build? > more information about uvesafb can be found here [2]. > > Thanx, > Mark > > [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=30342 > [2] http://dev.gentoo.org/~spock/projects/uvesafb/ > I can actually see a use for this: debugging video BIOS code could be much easier. But who wwould maintain the v86d userspace code package if we enabled the driver? From notting at redhat.com Tue Jan 8 17:05:13 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 8 Jan 2008 12:05:13 -0500 Subject: UVESAFB in kernel 2.6.24 In-Reply-To: <6e24a8e80801080857s1d19157bo5c43c46ce09e65e0@mail.gmail.com> References: <6e24a8e80801080630id46272fq28e0cd30ae724d39@mail.gmail.com> <20080108165146.GA2792@nostromo.devel.redhat.com> <6e24a8e80801080857s1d19157bo5c43c46ce09e65e0@mail.gmail.com> Message-ID: <20080108170513.GD2792@nostromo.devel.redhat.com> Mark (markg85 at gmail.com) said: > > Why wouldn't it be a module like (most) other framebuffers? > > Well.. vesafb is also enabled with 'y' and because uvesafb is it's > successor it seems logical to me that it also gets enabled with 'y' > (not as a module but build in). Perhaps a good idea for fedora to add > a anaconda installer option that allows you to set the boot resolution > or add the option in the firstboot. AFAIK, we don't ship the tools for uvesafb, so it's a little late for it to be a successor. How does it execute them if it's built-in, anyway? Bill From jumbomail_admin2 at libero.it Tue Jan 8 17:40:32 2008 From: jumbomail_admin2 at libero.it (angedouglass@libero.it) Date: Tue, 8 Jan 2008 12:40:32 -0500 Subject: Hello My Dear, Message-ID: <18542774.1199814026885.JavaMail.root@jumbomail2> Hello My Dear, Good a thing to write you. I have a proposal for you. The following information is my purpose for seeking a God fearing, sincere and trust-worthy foreign business partner who will please take me as is own and act on my behalf. I am Miss Ange douglass, the only dougther of douglass kadulah (The managing director of oil company. he died in sudan during the war Then, i managed to escape for my dear life and ran another country, (ABIDJAN) the capital commercial city of (COTE D' IVOIRE) where my father's wealth is. Before my father died he made his final WILL and i am the beneficiary of his WILL. In accordance with paragraph 9(ii) of his last Testamentary Disposition as directed by him, my daddy made me his Next of Kin to the sum of USD$ 6.7 Million in his Domicilary USDollar account with bank of Cote D' Ivoire. Now my dear, this information i revealed to you is my life, and i beleive you will never betray me This is as regards the distribution of all sums standing in his name in his USD Savings and Current Account with bank of Cote d' Ivoire. So I need your assistance to help me claim and transfer this money into your company or private bank account in your country and as soon as bank transfers the money into your bank account, Upon the declaration of your interest i will email you with the contact information of the International Remittance Department of the bank of Cote d' Ivoire, and provide you with any necessary document needed for you to claim the money on my behalf. the documents are with me here. You can as well reached me with this email(angedouglass at yahoo.ca) Now permit me to ask these few questions:- 1. Can you honestly help me as your daughter? 2. Can I completely trust you? 3. What percentage of the total amount in question. Please, Consider this and get back to me as soon as possible. sincerely regards Ange Douglass. Jumbo Mail ? il servizio di Libero Mail che permette di allegare grossi file, fino a 2GB, senza problemi di superamento dei limiti delle normali caselle e-mail. http://liberomail.libero.it/jumbomail.phtml From markg85 at gmail.com Tue Jan 8 18:10:44 2008 From: markg85 at gmail.com (Mark) Date: Tue, 8 Jan 2008 19:10:44 +0100 Subject: UVESAFB in kernel 2.6.24 In-Reply-To: <20080108170513.GD2792@nostromo.devel.redhat.com> References: <6e24a8e80801080630id46272fq28e0cd30ae724d39@mail.gmail.com> <20080108165146.GA2792@nostromo.devel.redhat.com> <6e24a8e80801080857s1d19157bo5c43c46ce09e65e0@mail.gmail.com> <20080108170513.GD2792@nostromo.devel.redhat.com> Message-ID: <6e24a8e80801081010x53c2b23cxe020c5e469cdd5e4@mail.gmail.com> 2008/1/8, Bill Nottingham : > AFAIK, we don't ship the tools for uvesafb, so it's a little late for > it to be a successor. How does it execute them if it's built-in, anyway? > > Bill uvesafb just got included in the 2.6.24 which isn't even final yet so it's not 'late'.. more early than late. To execute.. Quote from [1]: "add video=uvesafb:1024x768-32,mtrr:3,ywrap (or similar) to your kernel command line" About the question: "But who wwould maintain the v86d userspace code package if we enabled the driver?" I'm willing to give it a shot with the help of someone that has experience in making spec files. (i have the links to the (old) handbooks.. just not the experience) [1] http://dev.gentoo.org/~spock/projects/uvesafb/ From notting at redhat.com Tue Jan 8 18:15:30 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 8 Jan 2008 13:15:30 -0500 Subject: UVESAFB in kernel 2.6.24 In-Reply-To: <6e24a8e80801081010x53c2b23cxe020c5e469cdd5e4@mail.gmail.com> References: <6e24a8e80801080630id46272fq28e0cd30ae724d39@mail.gmail.com> <20080108165146.GA2792@nostromo.devel.redhat.com> <6e24a8e80801080857s1d19157bo5c43c46ce09e65e0@mail.gmail.com> <20080108170513.GD2792@nostromo.devel.redhat.com> <6e24a8e80801081010x53c2b23cxe020c5e469cdd5e4@mail.gmail.com> Message-ID: <20080108181530.GA8371@nostromo.devel.redhat.com> Mark (markg85 at gmail.com) said: > > AFAIK, we don't ship the tools for uvesafb, so it's a little late for > > it to be a successor. How does it execute them if it's built-in, anyway? > > uvesafb just got included in the 2.6.24 which isn't even final yet so > it's not 'late'.. more early than late. Sorry, meant 'too early', without the userspace part. > To execute.. Quote from [1]: > "add video=uvesafb:1024x768-32,mtrr:3,ywrap (or similar) to your > kernel command line" Right, but how does that work if built-in static? Is it relying on initialization order vs. initramfs unpacking to find its userspace component? Is it just spinning waiting for userspace? > About the question: > "But who wwould maintain the v86d userspace code package if we enabled the > driver?" > > I'm willing to give it a shot with the help of someone that has > experience in making spec files. (i have the links to the (old) > handbooks.. just not the experience) > > [1] http://dev.gentoo.org/~spock/projects/uvesafb/ This includes Yet Another Pasted In Copy of x86emu and lrmi. Ick. We really need to get a single libx86 in the distro and have things using it. Bill From markg85 at gmail.com Tue Jan 8 18:24:33 2008 From: markg85 at gmail.com (Mark) Date: Tue, 8 Jan 2008 19:24:33 +0100 Subject: UVESAFB in kernel 2.6.24 In-Reply-To: <20080108181530.GA8371@nostromo.devel.redhat.com> References: <6e24a8e80801080630id46272fq28e0cd30ae724d39@mail.gmail.com> <20080108165146.GA2792@nostromo.devel.redhat.com> <6e24a8e80801080857s1d19157bo5c43c46ce09e65e0@mail.gmail.com> <20080108170513.GD2792@nostromo.devel.redhat.com> <6e24a8e80801081010x53c2b23cxe020c5e469cdd5e4@mail.gmail.com> <20080108181530.GA8371@nostromo.devel.redhat.com> Message-ID: <6e24a8e80801081024w23ba6d93je8073e175c0305aa@mail.gmail.com> > > To execute.. Quote from [1]: > > "add video=uvesafb:1024x768-32,mtrr:3,ywrap (or similar) to your > > kernel command line" > > Right, but how does that work if built-in static? Is it relying > on initialization order vs. initramfs unpacking to find its userspace > component? Is it just spinning waiting for userspace? The readme says: 4. Installation & Usage ----------------------- To configure, build and install v86d with the default settings, run: # ./configure --default # make # make install v86d isn't meant to be used in an interactive way. It should be started and called by the kernel. If you want to see it in action, build and load the uvesafb kernel module. If you want to include v86d into an initramfs image, misc/initramfs provides a minimal config parsable by gen_init_cpio. misc/initramfs says: dir /dev 0755 0 0 nod /dev/console 0600 0 0 c 5 1 nod /dev/tty1 0600 0 0 c 4 1 nod /dev/zero 0600 0 0 c 1 5 nod /dev/mem 0600 0 0 c 1 1 dir /root 0700 0 0 dir /sbin 0755 0 0 file /sbin/v86d /sbin/v86d 0755 0 0 I think the module simply has to be included with initramfs In general i'm not sure how this is supposed to work. only that it solves my widescreen issue and that it's less difficult to use than just vesafb (because that uses codes for the resolution while this one uses a readable text (like 1280x800)) From j.w.r.degoede at hhs.nl Wed Jan 9 21:44:49 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 09 Jan 2008 22:44:49 +0100 Subject: Linux scsi / usb-mass-storage and HP printer cardreader bug + fix Message-ID: <47854051.1060307@hhs.nl> Hi All, First of all sorry for the somewhat massive cross-posting, I've spend a significant amount of time hunting down this bug, and so far the response has been less the overwhelming. The problem is with the HP PSC 1350 (my printer and confirmed by 2 others) and atleast also the HP PSC 1610 (confirmed by Guillaume Bedot, in the CC). The cardreader of the multi function printers will "crash" and from that moment on no longer communicate in any sane way, if you try to read the last sector of an sdcard* in a read that is more then 1 sector, so trying to read 8 sectors starting at sector capicity-8 will crash it, as will reading 2 sectors starting at sector capicity-2, however reading the last sector in a one 1 sector read will succeed! (* xdcards seem to be fine). I haven't tried if it will crash on larger then 1 sector writes which include the last sector too, I immediately added code to not do that in both the read and write paths. I have tested reading and writing the end of the disk with this kludge in and it works. I currently have a somewhat ugly proof of concept patch for this, which adds another type of usb-massstorage quirk. When this quirk flag is set, the usb-massstorage driver modifies READ_10 and WRITE_10 commands of more then 1 sector which includes the last sector to become one sector less. I've been told by scsi subsystem developers that doing a shorter read / write then requested is not a problem, the scsi subsystem is designed to handle getting less then it asked for and will send a seperate request for the last sector. I and 3 others (2 on a PSC 1350 too, one on a PSC1610) have tested this patch with success. I'm not asking for this patch to be included to the kernel as is, I'm asking for the now known workaround for this to be added to the kernel in someway! Perhaps its an idea to add the posibility to have a scsi command filter function / callback to the scsi or usb-massstorage subsystem, and then add a mechanism to set this filter depending on usb id's and if added to the scsi layer, a mechanism to set it based on scsi device and manufacturer identification strings. Such a mechanism might be usefull in the future to work around other broken hardware too, and has the added advantage of not having todo much changes to the normal code path, keep that readable. I'm willing to come up with a patch for such a filter mechanism, provided I get some pointers where this is best added. Thanks & Regards, Hans p.s. I've also included the fedora-kernel list in the addressee's because I was hoping that maybe someone can take one of these printers to the kernel hackfest in the weekend's fudcon and take a look at this. -------------- next part -------------- A non-text attachment was scrubbed... Name: usb-storage-psc1350-v3.patch Type: text/x-patch Size: 8631 bytes Desc: not available URL: From mdharm-scsi at one-eyed-alien.net Wed Jan 9 22:10:46 2008 From: mdharm-scsi at one-eyed-alien.net (Matthew Dharm) Date: Wed, 9 Jan 2008 14:10:46 -0800 Subject: [linux-usb-devel] Linux scsi / usb-mass-storage and HP printer cardreader bug + fix In-Reply-To: <47854051.1060307@hhs.nl> References: <47854051.1060307@hhs.nl> Message-ID: <20080109221046.GD14375@one-eyed-alien.net> On Wed, Jan 09, 2008 at 10:44:49PM +0100, Hans de Goede wrote: > First of all sorry for the somewhat massive cross-posting, I've spend a > significant amount of time hunting down this bug, and so far the response > has been less the overwhelming. > The cardreader of the multi function printers will "crash" and from that > moment on no longer communicate in any sane way, if you try to read the > last sector of an sdcard* in a read that is more then 1 sector, so trying > to read 8 sectors starting at sector capicity-8 will crash it, as will > reading 2 sectors starting at sector capicity-2, however reading the last > sector in a one 1 sector read will succeed! (* xdcards seem to be fine). To continue the history on this.... we over in usb-storage land looked at this and think it belongs in the SCSI layer. We don't like changing commands in-flight; it has, historically, caused us all sorts of issues in the past. Furthermore, this seems like the likely sort of off-by-one bug that can affect many types of devices, not just USB. I'd really like to see this in sd_mod -- I have no objection to requiring an HCD to set a flag to indicate that it should be used, if really desired. But, it seems to me to be a much easier change to make where the command originated rather than in mid-flight. Matt -- Matthew Dharm Home: mdharm-usb at one-eyed-alien.net Maintainer, Linux USB Mass Storage Driver P: Nine more messages in admin.policy. M: I know, I'm typing as fast as I can! -- Pitr and Mike User Friendly, 11/27/97 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From SWISSLOTTO at ONLINEGAMES.ORG Thu Jan 10 10:09:48 2008 From: SWISSLOTTO at ONLINEGAMES.ORG (SWISS LOTTO PROMOTIONS) Date: Thu, 10 Jan 2008 21:09:48 +1100 Subject: Internet Emails Award Call Your Claims Agent (Mr Luis Johnson) Message-ID: SWISS-LOTTO NETHERLANDS Palistrinalaan 44, 8011vn, Zwolle Netherlands https://www.swisslotto.ch !!!CONGRATULATION YOU ARE A WINNER!!!. The Board of Directors, members of staff and the International Promotion Department of the SWISS-LOTTO Satellite lottery, Netherlands, wishes to congratulate you on your success as the STAR PRIZE WINNER in this years' SWISS-LOTTO Satellite lottery Netherlands International Promotion (SLP) .The late notice was due to mix up email addresses, no tickets were sold, and you were randomly selected as a winner. This comes with a prize of Seven Hundred and Fifty Thousand Euro (?750,000) Euros in the SWISS-LOTTO Satellite Software email lottery in which e-mail addresses are picked randomly by Software powered by the Internet through the worldwide website. Your email address was amongst those chosen this year for the SWISS-LOTTO Satellite lottery. And this promotion is proudly sponsored by the SWISS-LOTTO NETHERLANDS organization. The selection process was carried out through random selection in our Computerized Email Selection System (C.E.S.S.) from a database of over a million email addresses from the World Wide Web. Each email address was attached to a ticket number and your email address with ticket number: KY/098/HG/7BN was randomly selected as the star prize winner amongst other consolation prize winners. Your email address, attached to Ref number 18, 43, 5, 7, 14, 17 with Serial number SLN/2378-32 drew the lucky Numbers 56, and consequently won the lottery in the "A" Category. You have therefore been approved for a lump sum pay out of ? 750,000 Euros.( Seven Hundred and Fifty Thousand Euros). Please note that your lucky winning number falls within our European Booklet representative office in Europe as indicated in your play coupon. In View of this, your ? 750,000 Euros will be released to you by our accredited claims agent located in Europe. Our European agent will immediately commence the process to facilitate the release of your winning funds as soon as you contact them. To file for your claim, kindly fill the verification form below and send it to the accredited Claims Manager, Mr. Luis Johnson of the claims department through email, stating your receipt of this notification. He has been mandated to offer you assistance and facilitate the urgent delivery of your prizes. Provide our/your accredited claims agent with the information as stated below: Mr. Luis Johnson Tel: +31619705470 Fax:+31847597673 Email: fudiciaryagent at mixmail.com VERIFICATION FORM: 1.) FULL NAME: 2.) AGE: 3.) SEX: 4.) MARITAL STATUS: 5.) ADDRESS: 6.) DRAW NUMBER ABOVE: 7.) OCCUPATION: 8.) COUNTRY OF RESIDENT: 9.) NATIONALITY: 10.) PHONE: 11.) FAX NUMBER: Thanks for been part of this promotional award programm.We wish you the best of lucky as you spend your good fortune. Sincerely, Hans William SWISS-LOTTO NETHERLANDS. Palistrinalaan 44, 8011vn, Zwolle Netherlands https://www.swisslotto.ch N.B: Keep all lotto information from public to avoid double claims, as any breach of confidentiality on the part of the winners will result to disqualification. From bharrosh at panasas.com Thu Jan 10 10:43:25 2008 From: bharrosh at panasas.com (Boaz Harrosh) Date: Thu, 10 Jan 2008 12:43:25 +0200 Subject: Linux scsi / usb-mass-storage and HP printer cardreader bug + fix In-Reply-To: <47854051.1060307@hhs.nl> References: <47854051.1060307@hhs.nl> Message-ID: <4785F6CD.6050907@panasas.com> ----- Original Message ----- *From:* Hans de Goede *To:* USB Storage list *CC:* fedora-kernel-list at redhat.com, USB development list , David Brown , Guillaume Bedot , linux-scsi at vger.kernel.org, linux-usb at vger.kernel.org *Sent:* Wed, Jan 09 2008 at 23:44 +0200 *Subject:* Linux scsi / usb-mass-storage and HP printer cardreader bug + fix > Hi All, > > First of all sorry for the somewhat massive cross-posting, I've spend a > significant amount of time hunting down this bug, and so far the response has > been less the overwhelming. > > The problem is with the HP PSC 1350 (my printer and confirmed by 2 others) and > atleast also the HP PSC 1610 (confirmed by Guillaume Bedot, in the CC). > > The cardreader of the multi function printers will "crash" and from that moment > on no longer communicate in any sane way, if you try to read the last sector of > an sdcard* in a read that is more then 1 sector, so trying to read 8 sectors > starting at sector capicity-8 will crash it, as will reading 2 sectors starting > at sector capicity-2, however reading the last sector in a one 1 sector read > will succeed! (* xdcards seem to be fine). > > I haven't tried if it will crash on larger then 1 sector writes which include > the last sector too, I immediately added code to not do that in both the read > and write paths. I have tested reading and writing the end of the disk with > this kludge in and it works. > > I currently have a somewhat ugly proof of concept patch for this, which adds > another type of usb-massstorage quirk. When this quirk flag is set, the > usb-massstorage driver modifies READ_10 and WRITE_10 commands of more then 1 > sector which includes the last sector to become one sector less. I've been told > by scsi subsystem developers that doing a shorter read / write then requested > is not a problem, the scsi subsystem is designed to handle getting less then it > asked for and will send a seperate request for the last sector. > > I and 3 others (2 on a PSC 1350 too, one on a PSC1610) have tested this patch > with success. I'm not asking for this patch to be included to the kernel as is, > I'm asking for the now known workaround for this to be added to the kernel in > someway! > > Perhaps its an idea to add the posibility to have a scsi command filter > function / callback to the scsi or usb-massstorage subsystem, and then add a > mechanism to set this filter depending on usb id's and if added to the scsi > layer, a mechanism to set it based on scsi device and manufacturer > identification strings. Such a mechanism might be usefull in the future to work > around other broken hardware too, and has the added advantage of not having > todo much changes to the normal code path, keep that readable. > > I'm willing to come up with a patch for such a filter mechanism, provided I get > some pointers where this is best added. > > Thanks & Regards, > > Hans > > > p.s. > > I've also included the fedora-kernel list in the addressee's because I was > hoping that maybe someone can take one of these printers to the kernel hackfest > in the weekend's fudcon and take a look at this. > > + if ((offset + num) == sdkp->capacity && num > 1) { > + if (srb->cmnd[8] == 0) > + srb->cmnd[7]--; > + srb->cmnd[8]--; > + srb->request_bufflen -= 512; > + srb->underflow -= 512; > + } > This will no longer compile on top of latest scsi-misc, and LLDs are not suppose to modify request_bufflen anymore. I'm not sure what the proper solution should be? Boaz From j.w.r.degoede at hhs.nl Thu Jan 10 10:52:56 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 10 Jan 2008 11:52:56 +0100 Subject: Linux scsi / usb-mass-storage and HP printer cardreader bug + fix In-Reply-To: <4785F6CD.6050907@panasas.com> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> Message-ID: <4785F908.3080307@hhs.nl> Boaz Harrosh wrote: > ----- Original Message ----- > *From:* Hans de Goede > *To:* USB Storage list > *CC:* fedora-kernel-list at redhat.com, USB development list > , David Brown > , Guillaume Bedot , > linux-scsi at vger.kernel.org, linux-usb at vger.kernel.org > *Sent:* Wed, Jan 09 2008 at 23:44 +0200 > *Subject:* Linux scsi / usb-mass-storage and HP printer cardreader bug + fix > > >> Hi All, >> >> First of all sorry for the somewhat massive cross-posting, I've spend a >> significant amount of time hunting down this bug, and so far the response has >> been less the overwhelming. >> >> The problem is with the HP PSC 1350 (my printer and confirmed by 2 others) and >> atleast also the HP PSC 1610 (confirmed by Guillaume Bedot, in the CC). >> >> The cardreader of the multi function printers will "crash" and from that moment >> on no longer communicate in any sane way, if you try to read the last sector of >> an sdcard* in a read that is more then 1 sector, so trying to read 8 sectors >> starting at sector capicity-8 will crash it, as will reading 2 sectors starting >> at sector capicity-2, however reading the last sector in a one 1 sector read >> will succeed! (* xdcards seem to be fine). >> >> I haven't tried if it will crash on larger then 1 sector writes which include >> the last sector too, I immediately added code to not do that in both the read >> and write paths. I have tested reading and writing the end of the disk with >> this kludge in and it works. >> >> I currently have a somewhat ugly proof of concept patch for this, which adds >> another type of usb-massstorage quirk. When this quirk flag is set, the >> usb-massstorage driver modifies READ_10 and WRITE_10 commands of more then 1 >> sector which includes the last sector to become one sector less. I've been told >> by scsi subsystem developers that doing a shorter read / write then requested >> is not a problem, the scsi subsystem is designed to handle getting less then it >> asked for and will send a seperate request for the last sector. >> >> I and 3 others (2 on a PSC 1350 too, one on a PSC1610) have tested this patch >> with success. I'm not asking for this patch to be included to the kernel as is, >> I'm asking for the now known workaround for this to be added to the kernel in >> someway! >> >> Perhaps its an idea to add the posibility to have a scsi command filter >> function / callback to the scsi or usb-massstorage subsystem, and then add a >> mechanism to set this filter depending on usb id's and if added to the scsi >> layer, a mechanism to set it based on scsi device and manufacturer >> identification strings. Such a mechanism might be usefull in the future to work >> around other broken hardware too, and has the added advantage of not having >> todo much changes to the normal code path, keep that readable. >> >> I'm willing to come up with a patch for such a filter mechanism, provided I get >> some pointers where this is best added. >> >> Thanks & Regards, >> >> Hans >> >> >> p.s. >> >> I've also included the fedora-kernel list in the addressee's because I was >> hoping that maybe someone can take one of these printers to the kernel hackfest >> in the weekend's fudcon and take a look at this. >> >> + if ((offset + num) == sdkp->capacity && num > 1) { >> + if (srb->cmnd[8] == 0) >> + srb->cmnd[7]--; >> + srb->cmnd[8]--; >> + srb->request_bufflen -= 512; >> + srb->underflow -= 512; >> + } >> > This will no longer compile on top of latest scsi-misc, and > LLDs are not suppose to modify request_bufflen anymore. > > I'm not sure what the proper solution should be? > I guess the proper solution would be to add a special case to the scsi layer where the read10 / write10 command is issued, and split the request in 2 there when it involves the last sector. There was another reply in this thread stating that problems reading the last sector with sd / mmc cards happen quite often, and that this is most likely not an isolated case. Regards, Hans From bharrosh at panasas.com Thu Jan 10 11:27:02 2008 From: bharrosh at panasas.com (Boaz Harrosh) Date: Thu, 10 Jan 2008 13:27:02 +0200 Subject: Linux scsi / usb-mass-storage and HP printer cardreader bug + fix In-Reply-To: <4785F908.3080307@hhs.nl> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> Message-ID: <47860106.3090509@panasas.com> On Thu, Jan 10 2008 at 12:52 +0200, Hans de Goede wrote: > Boaz Harrosh wrote: >> ----- Original Message ----- >> *From:* Hans de Goede >> *To:* USB Storage list >> *CC:* fedora-kernel-list at redhat.com, USB development list >> , David Brown >> , Guillaume Bedot , >> linux-scsi at vger.kernel.org, linux-usb at vger.kernel.org >> *Sent:* Wed, Jan 09 2008 at 23:44 +0200 >> *Subject:* Linux scsi / usb-mass-storage and HP printer cardreader bug + fix >> >> >>> Hi All, >>> >>> First of all sorry for the somewhat massive cross-posting, I've spend a >>> significant amount of time hunting down this bug, and so far the response has >>> been less the overwhelming. >>> >>> The problem is with the HP PSC 1350 (my printer and confirmed by 2 others) and >>> atleast also the HP PSC 1610 (confirmed by Guillaume Bedot, in the CC). >>> >>> The cardreader of the multi function printers will "crash" and from that moment >>> on no longer communicate in any sane way, if you try to read the last sector of >>> an sdcard* in a read that is more then 1 sector, so trying to read 8 sectors >>> starting at sector capicity-8 will crash it, as will reading 2 sectors starting >>> at sector capicity-2, however reading the last sector in a one 1 sector read >>> will succeed! (* xdcards seem to be fine). >>> >>> I haven't tried if it will crash on larger then 1 sector writes which include >>> the last sector too, I immediately added code to not do that in both the read >>> and write paths. I have tested reading and writing the end of the disk with >>> this kludge in and it works. >>> >>> I currently have a somewhat ugly proof of concept patch for this, which adds >>> another type of usb-massstorage quirk. When this quirk flag is set, the >>> usb-massstorage driver modifies READ_10 and WRITE_10 commands of more then 1 >>> sector which includes the last sector to become one sector less. I've been told >>> by scsi subsystem developers that doing a shorter read / write then requested >>> is not a problem, the scsi subsystem is designed to handle getting less then it >>> asked for and will send a seperate request for the last sector. >>> >>> I and 3 others (2 on a PSC 1350 too, one on a PSC1610) have tested this patch >>> with success. I'm not asking for this patch to be included to the kernel as is, >>> I'm asking for the now known workaround for this to be added to the kernel in >>> someway! >>> >>> Perhaps its an idea to add the posibility to have a scsi command filter >>> function / callback to the scsi or usb-massstorage subsystem, and then add a >>> mechanism to set this filter depending on usb id's and if added to the scsi >>> layer, a mechanism to set it based on scsi device and manufacturer >>> identification strings. Such a mechanism might be usefull in the future to work >>> around other broken hardware too, and has the added advantage of not having >>> todo much changes to the normal code path, keep that readable. >>> >>> I'm willing to come up with a patch for such a filter mechanism, provided I get >>> some pointers where this is best added. >>> >>> Thanks & Regards, >>> >>> Hans >>> >>> >>> p.s. >>> >>> I've also included the fedora-kernel list in the addressee's because I was >>> hoping that maybe someone can take one of these printers to the kernel hackfest >>> in the weekend's fudcon and take a look at this. >>> >>> + if ((offset + num) == sdkp->capacity && num > 1) { >>> + if (srb->cmnd[8] == 0) >>> + srb->cmnd[7]--; >>> + srb->cmnd[8]--; >>> + srb->request_bufflen -= 512; >>> + srb->underflow -= 512; >>> + } >>> >> This will no longer compile on top of latest scsi-misc, and >> LLDs are not suppose to modify request_bufflen anymore. >> >> I'm not sure what the proper solution should be? >> > > I guess the proper solution would be to add a special case to the scsi layer > where the read10 / write10 command is issued, and split the request in 2 there > when it involves the last sector. > > There was another reply in this thread stating that problems reading the last > sector with sd / mmc cards happen quite often, and that this is most likely not > an isolated case. > > Regards, > > Hans Yes, you're right. in ULDs it is a much proper way to do this. So I guess you'll have to do that special host flag or device flag, and add a check for it in sd.c. You'll see that sd.c is already doing bufflen truncation at sd_prep_fn(), just add one more case. Boaz From E-Cards at hallmark.com Thu Jan 10 12:27:15 2008 From: E-Cards at hallmark.com (hallmark.com) Date: Thu, 10 Jan 2008 21:27:15 +0900 (JST) Subject: You've received A Hallmark E-Card! Message-ID: <20080110122715.35C85A24B1@localhost> An HTML attachment was scrubbed... URL: From j.w.r.degoede at hhs.nl Thu Jan 10 15:04:14 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 10 Jan 2008 16:04:14 +0100 Subject: IIDC camera's and the juju firewirestack Message-ID: <478633EE.2030407@hhs.nl> Hi All, In the thread I started about Fedora perhaps being to cutting edge, it was said that I shouldn't complain as there is only one problem left with the juju stack which is a bug with via vt6306 cards in OHCI 1.0 cards. Further analysis of the problem has learned that this is not true, I'm using a via vt6306 card in OHCI 1.1 mode, which allegedly should work fine. However most documents talk about using the juju stack with either harddisks or DV for homevideo camera's. However I'm trying to use an industrial cam which used the IIDC protocol, and support in the new juju stack (kernel + userspace) for the IIDC protocol isn't very good. As the consensus from the other thread seems to be that having 2 parallel stacks is not a good plan, I have decided to spend some time to get the IIDC situation with the juju stack improved. However I'm pretty new to all this, so I will need a couple of pointers to get me up to speed. I've been testing with the grab_gray_image example from libdc1394-2.0.0. The problem is that it hangs at the dc1394_capture_dequeue(camera, DC1394_CAPTURE_POLICY_WAIT, &frame) call. The camera does seem to be sending data, as its activity led is flickering. Any clues for further debugging this would be much appreciated, shall I put this in bugzilla? If so against which component? Regards, Hans p.s. Yes I know that libdc1394 currently is not in Fedora, but that can be changed, it has some pieces of patented code, but those can be disabled using a ./configure option -> are #ifdef'd and can thus be removed automatically from the source code using some special tools. From jwilson at redhat.com Thu Jan 10 15:27:38 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 10 Jan 2008 10:27:38 -0500 Subject: IIDC camera's and the juju firewirestack In-Reply-To: <478633EE.2030407@hhs.nl> References: <478633EE.2030407@hhs.nl> Message-ID: <4786396A.4060605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hans de Goede wrote: > In the thread I started about Fedora perhaps being to cutting edge, it > was said that I shouldn't complain as there is only one problem left > with the juju stack which is a bug with via vt6306 cards in OHCI 1.0 cards. Oh, there's definitely more than one problem left... :) > Further analysis of the problem has learned that this is not true, I'm > using a via vt6306 card in OHCI 1.1 mode, which allegedly should work fine. The particular bug is actually related to vt6306 and vt6307 cards in OHCI 1.0 mode doing dv capture. iidc is much less tested. I already know where at least a few of the iidc-related OHCI 1.0 bugs are, but they shouldn't be impacting you... I've also got an idea or two on what's up with dv capture, just need to get the spare cycles to test (which could happen shortly, just finished a major piece of lirc...) > However most documents talk about using the juju stack with either > harddisks or DV for homevideo camera's. However I'm trying to use an > industrial cam which used the IIDC protocol, and support in the new juju > stack (kernel + userspace) for the IIDC protocol isn't very good. I believe David Moore's patch in linux1394-2.6.git[*] should help, and it looks like that also needs to be ported over to the OHCI 1.0 code paths... > As the consensus from the other thread seems to be that having 2 > parallel stacks is not a good plan, I have decided to spend some time to > get the IIDC situation with the juju stack improved. However I'm pretty > new to all this, so I will need a couple of pointers to get me up to speed. Awesome, we definitely need more help. Neither krh nor I is able to spend quite as much time on juju as we'd like right now... > I've been testing with the grab_gray_image example from libdc1394-2.0.0. > The problem is that it hangs at the dc1394_capture_dequeue(camera, > DC1394_CAPTURE_POLICY_WAIT, &frame) call. > > The camera does seem to be sending data, as its activity led is flickering. > > Any clues for further debugging this would be much appreciated That git patch would be the first step. I'll look at doing similar for OHCI 1.0, as well as testing out an idea I had wrt dv capture on OHCI 1.0... > shall I put this in bugzilla? Might as well. Some of it is already there, but nothing iidc-specific yet. > If so against which component? I'd file it against kernel, but assign it to me and cc krh at redhat.com and fenlason at redhat.com. [*] http://git.kernel.org/?p=linux/kernel/git/ieee1394/linux1394-2.6.git;a=commitdiff;h=e9f5ca46377ac60a6b7d52c6c19a1661c87c6e20 - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhjlqtO+bni+75QMRAptqAJ4ndhFsNe9yyHVzjKVv7Mlzq7wHbACg0FFB eOsRcGVaAUtv7QbgEus+np4= =K0/M -----END PGP SIGNATURE----- From jwilson at redhat.com Thu Jan 10 18:43:15 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 10 Jan 2008 13:43:15 -0500 Subject: IIDC camera's and the juju firewirestack In-Reply-To: <4786396A.4060605@redhat.com> References: <478633EE.2030407@hhs.nl> <4786396A.4060605@redhat.com> Message-ID: <47866743.8020608@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jarod Wilson wrote: > Hans de Goede wrote: >> In the thread I started about Fedora perhaps being to cutting edge, it >> was said that I shouldn't complain as there is only one problem left >> with the juju stack which is a bug with via vt6306 cards in OHCI 1.0 cards. > > Oh, there's definitely more than one problem left... :) > >> Further analysis of the problem has learned that this is not true, I'm >> using a via vt6306 card in OHCI 1.1 mode, which allegedly should work fine. > > The particular bug is actually related to vt6306 and vt6307 cards in OHCI 1.0 > mode doing dv capture. iidc is much less tested. I already know where at least > a few of the iidc-related OHCI 1.0 bugs are, but they shouldn't be impacting > you... I've also got an idea or two on what's up with dv capture, just need to > get the spare cycles to test (which could happen shortly, just finished a > major piece of lirc...) > >> However most documents talk about using the juju stack with either >> harddisks or DV for homevideo camera's. However I'm trying to use an >> industrial cam which used the IIDC protocol, and support in the new juju >> stack (kernel + userspace) for the IIDC protocol isn't very good. > > I believe David Moore's patch in linux1394-2.6.git[*] should help, and it > looks like that also needs to be ported over to the OHCI 1.0 code paths... Nope, looks like he's already done that too. As I said in another thread, I'm going to try to start tracking the linux1394 git tree in rawhide, and selectively pull back patches into released kernels. David's done a lot of excellent work of late while I was busy not paying attention, due to the holidays and other misc stuff (lirc, ia64 xen, ecryptfs, ext4...) - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhmdDtO+bni+75QMRAuXMAKCpQrPfZlS0fGOLqU4Lg2HRk2KxLACgy6xP yNP1JUzpzhAlOE5eGH6h4Go= =DZkp -----END PGP SIGNATURE----- From j.w.r.degoede at hhs.nl Fri Jan 11 09:21:46 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 11 Jan 2008 10:21:46 +0100 Subject: IDCC camera's & firewire juju stack In-Reply-To: <47863E82.4060307@s5r6.in-berlin.de> References: <4786340E.4060308@hhs.nl> <1199978334.28329.5.camel@aries.csail.mit.edu> <47863E82.4060307@s5r6.in-berlin.de> Message-ID: <4787352A.7020303@hhs.nl> Hi All, Thanks for all the help, I have it working now by building a 2.6.23 kernel with the patchset from here applied: http://me.in-berlin.de/~s5r6/linux1394/updates/ Then it works if I lower the number of buffer passed to dc1394_capture_setup() to 2, after also applying this patch: http://marc.info/?l=linux1394-devel&m=119965813322642 ? This is no longer needed and even coriander (from cvs) works fine! This is with a via vt6306 in OHCI 1.1 mode (which is the factory default for this pci card), should the above patches be enough to also get it to work in 1.0 mode? If that is the case I can try flashing it to 1.0 mode and see if that will also work. Regards, Hans p.s. Next step building libdc1394 and coriander packages for Fedora! From stefanr at s5r6.in-berlin.de Fri Jan 11 09:44:00 2008 From: stefanr at s5r6.in-berlin.de (Stefan Richter) Date: Fri, 11 Jan 2008 10:44:00 +0100 Subject: [libdc] IDCC camera's & firewire juju stack In-Reply-To: <4787352A.7020303@hhs.nl> References: <4786340E.4060308@hhs.nl> <1199978334.28329.5.camel@aries.csail.mit.edu> <47863E82.4060307@s5r6.in-berlin.de> <4787352A.7020303@hhs.nl> Message-ID: <47873A60.8030606@s5r6.in-berlin.de> Hans de Goede wrote: > Thanks for all the help, I have it working now by building a 2.6.23 kernel with > the patchset from here applied: > http://me.in-berlin.de/~s5r6/linux1394/updates/ > > Then it works if I lower the number of buffer passed to dc1394_capture_setup() > to 2, after also applying this patch: > http://marc.info/?l=linux1394-devel&m=119965813322642 ? > > This is no longer needed and even coriander (from cvs) works fine! > > This is with a via vt6306 in OHCI 1.1 mode (which is the factory default for > this pci card), should the above patches be enough to also get it to work in > 1.0 mode? If that is the case I can try flashing it to 1.0 mode and see if that > will also work. No, according to what several people saw with VT630x in OHCI 1.0 mode, there is still the bug that the DMA program stops after receiving one or a few frames. This is 100% reproducible with coriander + IIDC camera and dvgrab + DV camcorder. https://bugzilla.redhat.com/show_bug.cgi?id=415841 As far as I understood, this presumably happens because the problem which David Moore addressed with "fw-ohci: Fix for dualbuffer three-or-more buffers" is also present but unfixed in the packet-per-buffer code. -- Stefan Richter -=====-==--- ---= -=-== http://arcgraph.de/sr/ From j.w.r.degoede at hhs.nl Fri Jan 11 12:48:31 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 11 Jan 2008 13:48:31 +0100 Subject: Linux scsi / usb-mass-storage and HP printer cardreader bug + fix In-Reply-To: <47860106.3090509@panasas.com> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> Message-ID: <4787659F.9050607@hhs.nl> Boaz Harrosh wrote: > On Thu, Jan 10 2008 at 12:52 +0200, Hans de Goede wrote: >>> I'm not sure what the proper solution should be? >>> >> I guess the proper solution would be to add a special case to the scsi layer >> where the read10 / write10 command is issued, and split the request in 2 there >> when it involves the last sector. >> >> There was another reply in this thread stating that problems reading the last >> sector with sd / mmc cards happen quite often, and that this is most likely not >> an isolated case. >> >> Regards, >> >> Hans > > Yes, you're right. in ULDs it is a much proper way to do this. > > So I guess you'll have to do that special host flag or device > flag, and add a check for it in sd.c. You'll see that sd.c is > already doing bufflen truncation at sd_prep_fn(), just add one > more case. > Yes, That will work nicely, I'll write an updated patch this evening (when I have access to the printer to test again). Regards, Hans From littletux at zarb.org Fri Jan 11 13:57:36 2008 From: littletux at zarb.org (Guillaume Bedot) Date: Fri, 11 Jan 2008 14:57:36 +0100 Subject: Linux scsi / usb-mass-storage and HP printer cardreader bug + fix In-Reply-To: <4787659F.9050607@hhs.nl> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> <4787659F.9050607@hhs.nl> Message-ID: <1200059856.8316.8.camel@localhost> Hello, Le vendredi 11 janvier 2008 ? 13:48 +0100, Hans de Goede a ?crit : > That will work nicely, I'll write an updated patch this evening (when I have > access to the printer to test again). > Great news, i am impatient to test this new patch. I may face an other bug with the Transcend 1GB SD card, would be possible that the patch would be available for latests kernels ? Thanks in advance, Best regards, Guillaume B. From jwilson at redhat.com Fri Jan 11 14:26:39 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 11 Jan 2008 09:26:39 -0500 Subject: [libdc] IDCC camera's & firewire juju stack In-Reply-To: <47873A60.8030606@s5r6.in-berlin.de> References: <4786340E.4060308@hhs.nl> <1199978334.28329.5.camel@aries.csail.mit.edu> <47863E82.4060307@s5r6.in-berlin.de> <4787352A.7020303@hhs.nl> <47873A60.8030606@s5r6.in-berlin.de> Message-ID: <47877C9F.5000305@redhat.com> Stefan Richter wrote: > Hans de Goede wrote: >> Thanks for all the help, I have it working now by building a 2.6.23 kernel with >> the patchset from here applied: >> http://me.in-berlin.de/~s5r6/linux1394/updates/ >> >> Then it works if I lower the number of buffer passed to dc1394_capture_setup() >> to 2, after also applying this patch: >> http://marc.info/?l=linux1394-devel&m=119965813322642 ? >> >> This is no longer needed and even coriander (from cvs) works fine! >> >> This is with a via vt6306 in OHCI 1.1 mode (which is the factory default for >> this pci card), should the above patches be enough to also get it to work in >> 1.0 mode? If that is the case I can try flashing it to 1.0 mode and see if that >> will also work. I can take care of testing on an VT6306 OHCI 1.0 controller, as well as a VT6307 OHCI 1.0 controller. Just bumping to the latest linux1394 git code wasn't enough to get dv capture working (via dvgrab) on one of my VT6307 1.0 controllers, but I'm about to give it a go with the addition of David's dynamic buffer allocation patch. > No, according to what several people saw with VT630x in OHCI 1.0 mode, > there is still the bug that the DMA program stops after receiving one or > a few frames. This is 100% reproducible with coriander + IIDC camera > and dvgrab + DV camcorder. > https://bugzilla.redhat.com/show_bug.cgi?id=415841 > > As far as I understood, this presumably happens because the problem > which David Moore addressed with "fw-ohci: Fix for dualbuffer > three-or-more buffers" is also present but unfixed in the > packet-per-buffer code. I can probably get a similar fix added on top of the packet-per-buffer code today, if it is indeed still needed. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From dcm at MIT.EDU Fri Jan 11 15:28:40 2008 From: dcm at MIT.EDU (David Moore) Date: Fri, 11 Jan 2008 10:28:40 -0500 Subject: [libdc] IDCC camera's & firewire juju stack In-Reply-To: <47873A60.8030606@s5r6.in-berlin.de> References: <4786340E.4060308@hhs.nl> <1199978334.28329.5.camel@aries.csail.mit.edu> <47863E82.4060307@s5r6.in-berlin.de> <4787352A.7020303@hhs.nl> <47873A60.8030606@s5r6.in-berlin.de> Message-ID: <1200065320.18669.15.camel@pisces.mit.edu> On Fri, 2008-01-11 at 10:44 +0100, Stefan Richter wrote: > No, according to what several people saw with VT630x in OHCI 1.0 mode, > there is still the bug that the DMA program stops after receiving one or > a few frames. This is 100% reproducible with coriander + IIDC camera > and dvgrab + DV camcorder. > https://bugzilla.redhat.com/show_bug.cgi?id=415841 > > As far as I understood, this presumably happens because the problem > which David Moore addressed with "fw-ohci: Fix for dualbuffer > three-or-more buffers" is also present but unfixed in the > packet-per-buffer code. I thought I had fixed that in my "fw-ohci: Bug fixes for packet-per-buffer support" patch, but maybe it's still not working perfectly yet. I'm running out of ideas for why that still might not work so further testing or insights would be appreciated. -David From jwilson at redhat.com Fri Jan 11 15:41:26 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 11 Jan 2008 10:41:26 -0500 Subject: [libdc] IDCC camera's & firewire juju stack In-Reply-To: <1200065320.18669.15.camel@pisces.mit.edu> References: <4786340E.4060308@hhs.nl> <1199978334.28329.5.camel@aries.csail.mit.edu> <47863E82.4060307@s5r6.in-berlin.de> <4787352A.7020303@hhs.nl> <47873A60.8030606@s5r6.in-berlin.de> <1200065320.18669.15.camel@pisces.mit.edu> Message-ID: <47878E26.7010507@redhat.com> David Moore wrote: > On Fri, 2008-01-11 at 10:44 +0100, Stefan Richter wrote: >> No, according to what several people saw with VT630x in OHCI 1.0 mode, >> there is still the bug that the DMA program stops after receiving one or >> a few frames. This is 100% reproducible with coriander + IIDC camera >> and dvgrab + DV camcorder. >> https://bugzilla.redhat.com/show_bug.cgi?id=415841 >> >> As far as I understood, this presumably happens because the problem >> which David Moore addressed with "fw-ohci: Fix for dualbuffer >> three-or-more buffers" is also present but unfixed in the >> packet-per-buffer code. > > I thought I had fixed that in my "fw-ohci: Bug fixes for > packet-per-buffer support" patch That's what I was thinking/hoping, but... > but maybe it's still not working perfectly yet. ...I still can't get more than 1 or 2 frames of dv w/the OHCI 1.0 VT6307 I'm working with right now. :( > I'm running out of ideas for why that still might not > work so further testing or insights would be appreciated. I'm rather short on ideas too. I was really hoping the dynamic buffer allocation patch might help too, thinking maybe these cards were just exhausting the buffer and getting wedged, but no dice. Oh, I should also mention that I get some lockdep spew w/the dynamic buffer alloc patch added to the mix... (will get that report over to you via linux1394-devel though) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jwilson at redhat.com Fri Jan 11 17:21:45 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 11 Jan 2008 12:21:45 -0500 Subject: [libdc] IDCC camera's & firewire juju stack In-Reply-To: <47878E26.7010507@redhat.com> References: <4786340E.4060308@hhs.nl> <1199978334.28329.5.camel@aries.csail.mit.edu> <47863E82.4060307@s5r6.in-berlin.de> <4787352A.7020303@hhs.nl> <47873A60.8030606@s5r6.in-berlin.de> <1200065320.18669.15.camel@pisces.mit.edu> <47878E26.7010507@redhat.com> Message-ID: <4787A5A9.3070405@redhat.com> Jarod Wilson wrote: > David Moore wrote: >> On Fri, 2008-01-11 at 10:44 +0100, Stefan Richter wrote: >>> No, according to what several people saw with VT630x in OHCI 1.0 mode, >>> there is still the bug that the DMA program stops after receiving one or >>> a few frames. This is 100% reproducible with coriander + IIDC camera >>> and dvgrab + DV camcorder. >>> https://bugzilla.redhat.com/show_bug.cgi?id=415841 >>> >>> As far as I understood, this presumably happens because the problem >>> which David Moore addressed with "fw-ohci: Fix for dualbuffer >>> three-or-more buffers" is also present but unfixed in the >>> packet-per-buffer code. >> I thought I had fixed that in my "fw-ohci: Bug fixes for >> packet-per-buffer support" patch > > That's what I was thinking/hoping, but... > >> but maybe it's still not working perfectly yet. > > ...I still can't get more than 1 or 2 frames of dv w/the OHCI 1.0 VT6307 I'm > working with right now. :( On the positive side, I *do* have coriander displaying video from a Unibrain Fire-i hooked to this same controller now, so the remaining problems appear to be dv-specific. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From stefanr at s5r6.in-berlin.de Fri Jan 11 18:25:30 2008 From: stefanr at s5r6.in-berlin.de (Stefan Richter) Date: Fri, 11 Jan 2008 19:25:30 +0100 Subject: [libdc] IDCC camera's & firewire juju stack In-Reply-To: <4787A5A9.3070405@redhat.com> References: <4786340E.4060308@hhs.nl> <1199978334.28329.5.camel@aries.csail.mit.edu> <47863E82.4060307@s5r6.in-berlin.de> <4787352A.7020303@hhs.nl> <47873A60.8030606@s5r6.in-berlin.de> <1200065320.18669.15.camel@pisces.mit.edu> <47878E26.7010507@redhat.com> <4787A5A9.3070405@redhat.com> Message-ID: <4787B49A.2040200@s5r6.in-berlin.de> Jarod Wilson wrote: > Jarod Wilson wrote: >> ...I still can't get more than 1 or 2 frames of dv w/the OHCI 1.0 VT6307 I'm >> working with right now. :( > > On the positive side, I *do* have coriander displaying video from a Unibrain > Fire-i hooked to this same controller now, so the remaining problems appear to > be dv-specific. Confirmed. "v4 Dynamically allocate buffers for DMA descriptors" fixes reception with coriander on my VT6306 (OHCI 1.0). But dvgrab still doesn't work with this card. (Says to have captured one frame when exiting, file size is 144000 bytes.) -- Stefan Richter -=====-==--- ---= -=-== http://arcgraph.de/sr/ From dcm at MIT.EDU Fri Jan 11 18:50:51 2008 From: dcm at MIT.EDU (David Moore) Date: Fri, 11 Jan 2008 13:50:51 -0500 Subject: [libdc] IDCC camera's & firewire juju stack In-Reply-To: <4787B49A.2040200@s5r6.in-berlin.de> References: <4786340E.4060308@hhs.nl> <1199978334.28329.5.camel@aries.csail.mit.edu> <47863E82.4060307@s5r6.in-berlin.de> <4787352A.7020303@hhs.nl> <47873A60.8030606@s5r6.in-berlin.de> <1200065320.18669.15.camel@pisces.mit.edu> <47878E26.7010507@redhat.com> <4787A5A9.3070405@redhat.com> <4787B49A.2040200@s5r6.in-berlin.de> Message-ID: <1200077451.7530.1.camel@aries.csail.mit.edu> On Fri, 2008-01-11 at 19:25 +0100, Stefan Richter wrote: > Jarod Wilson wrote: > > On the positive side, I *do* have coriander displaying video from a Unibrain > > Fire-i hooked to this same controller now, so the remaining problems appear to > > be dv-specific. > > Confirmed. "v4 Dynamically allocate buffers for DMA descriptors" fixes > reception with coriander on my VT6306 (OHCI 1.0). But dvgrab still > doesn't work with this card. (Says to have captured one frame when > exiting, file size is 144000 bytes.) Can you confirm that with the same patch set dvgrab _does_ work on other types of OHCI 1.0 controllers? -David From stefanr at s5r6.in-berlin.de Fri Jan 11 19:05:01 2008 From: stefanr at s5r6.in-berlin.de (Stefan Richter) Date: Fri, 11 Jan 2008 20:05:01 +0100 Subject: [libdc] IDCC camera's & firewire juju stack In-Reply-To: <1200077451.7530.1.camel@aries.csail.mit.edu> References: <4786340E.4060308@hhs.nl> <1199978334.28329.5.camel@aries.csail.mit.edu> <47863E82.4060307@s5r6.in-berlin.de> <4787352A.7020303@hhs.nl> <47873A60.8030606@s5r6.in-berlin.de> <1200065320.18669.15.camel@pisces.mit.edu> <47878E26.7010507@redhat.com> <4787A5A9.3070405@redhat.com> <4787B49A.2040200@s5r6.in-berlin.de> <1200077451.7530.1.camel@aries.csail.mit.edu> Message-ID: <4787BDDD.1080600@s5r6.in-berlin.de> David Moore wrote: > On Fri, 2008-01-11 at 19:25 +0100, Stefan Richter wrote: >> "v4 Dynamically allocate buffers for DMA descriptors" fixes >> reception with coriander on my VT6306 (OHCI 1.0). But dvgrab still >> doesn't work with this card. (Says to have captured one frame when >> exiting, file size is 144000 bytes.) > > Can you confirm that with the same patch set dvgrab _does_ work on other > types of OHCI 1.0 controllers? With and without this patch dvgrab works on OHCI 1.0 Agere/LSI FW323 (Apple Mac mini onboard) and OHCI NEC something (OrangeLink CardBus card). -- Stefan Richter -=====-==--- ---= -=-== http://arcgraph.de/sr/ From j.w.r.degoede at hhs.nl Fri Jan 11 20:14:00 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 11 Jan 2008 21:14:00 +0100 Subject: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix) In-Reply-To: <47860106.3090509@panasas.com> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> Message-ID: <4787CE08.5000304@hhs.nl> Boaz Harrosh wrote: > Yes, you're right. in ULDs it is a much proper way to do this. > > So I guess you'll have to do that special host flag or device > flag, and add a check for it in sd.c. You'll see that sd.c is > already doing bufflen truncation at sd_prep_fn(), just add one > more case. > Done, thanks for the hint. Patch implementing my fix this way attached, please apply. Thanks & Regards, Hans -------------- next part -------------- A non-text attachment was scrubbed... Name: usb-storage-psc1350-v4.patch Type: text/x-patch Size: 7725 bytes Desc: not available URL: From jwilson at redhat.com Fri Jan 11 20:22:45 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 11 Jan 2008 15:22:45 -0500 Subject: IIDC camera's and the juju firewirestack In-Reply-To: <47866743.8020608@redhat.com> References: <478633EE.2030407@hhs.nl> <4786396A.4060605@redhat.com> <47866743.8020608@redhat.com> Message-ID: <4787D015.3000503@redhat.com> Jarod Wilson wrote: > Jarod Wilson wrote: >> Hans de Goede wrote: >>> In the thread I started about Fedora perhaps being to cutting edge, it >>> was said that I shouldn't complain as there is only one problem left >>> with the juju stack which is a bug with via vt6306 cards in OHCI 1.0 cards. >> Oh, there's definitely more than one problem left... :) > >>> Further analysis of the problem has learned that this is not true, I'm >>> using a via vt6306 card in OHCI 1.1 mode, which allegedly should work fine. >> The particular bug is actually related to vt6306 and vt6307 cards in OHCI 1.0 >> mode doing dv capture. iidc is much less tested. I already know where at least >> a few of the iidc-related OHCI 1.0 bugs are, but they shouldn't be impacting >> you... I've also got an idea or two on what's up with dv capture, just need to >> get the spare cycles to test (which could happen shortly, just finished a >> major piece of lirc...) > >>> However most documents talk about using the juju stack with either >>> harddisks or DV for homevideo camera's. However I'm trying to use an >>> industrial cam which used the IIDC protocol, and support in the new juju >>> stack (kernel + userspace) for the IIDC protocol isn't very good. >> I believe David Moore's patch in linux1394-2.6.git[*] should help, and it >> looks like that also needs to be ported over to the OHCI 1.0 code paths... > > Nope, looks like he's already done that too. As I said in another thread, I'm > going to try to start tracking the linux1394 git tree in rawhide, and > selectively pull back patches into released kernels. David's done a lot of > excellent work of late while I was busy not paying attention, due to the > holidays and other misc stuff (lirc, ia64 xen, ecryptfs, ext4...) After a bit of positive testing, I committed a linux1394 git patch plus David's dynamic buffer alloc patch, which is about to be in linux1394 git, to the rawhide kernel. We've now got working iidc streaming on all OHCI 1.0 and 1.1 cards, so far as I know. I'll see about back-porting these bits to the F7 and F8 kernels as well. Would definitely like to hear what *doesn't* work now, short of dv capture with Via VT630x OHCI 1.0 cards, which is known broken and under investigation. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mdharm-scsi at one-eyed-alien.net Fri Jan 11 20:34:24 2008 From: mdharm-scsi at one-eyed-alien.net (Matthew Dharm) Date: Fri, 11 Jan 2008 12:34:24 -0800 Subject: [usb-storage] PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix) In-Reply-To: <4787CE08.5000304@hhs.nl> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> <4787CE08.5000304@hhs.nl> Message-ID: <20080111203424.GE14375@one-eyed-alien.net> On Fri, Jan 11, 2008 at 09:14:00PM +0100, Hans de Goede wrote: > Boaz Harrosh wrote: > >Yes, you're right. in ULDs it is a much proper way to do this. > > > >So I guess you'll have to do that special host flag or device > >flag, and add a check for it in sd.c. You'll see that sd.c is > >already doing bufflen truncation at sd_prep_fn(), just add one > >more case. > > > > Done, thanks for the hint. Patch implementing my fix this way attached, > please apply. Well, I can't say that I'm really a big fan of matching a multi-interface device based on the interface class code, but I don't see a better solution that isn't a major coding project. This approach looks pretty reasonable to me. Matt -- Matthew Dharm Home: mdharm-usb at one-eyed-alien.net Maintainer, Linux USB Mass Storage Driver SP: I sell software for Microsoft. Can you set me free? DP: Natural Selection says I shouldn't. -- MS Salesman and Dust Puppy User Friendly, 4/2/1998 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Fri Jan 11 21:10:35 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 11 Jan 2008 22:10:35 +0100 Subject: IIDC camera's and the juju firewirestack In-Reply-To: <4787D015.3000503@redhat.com> References: <478633EE.2030407@hhs.nl> <4786396A.4060605@redhat.com> <47866743.8020608@redhat.com> <4787D015.3000503@redhat.com> Message-ID: <4787DB4B.4020005@hhs.nl> Jarod Wilson wrote: > Jarod Wilson wrote: >> Jarod Wilson wrote: >>> Hans de Goede wrote: >>>> In the thread I started about Fedora perhaps being to cutting edge, it >>>> was said that I shouldn't complain as there is only one problem left >>>> with the juju stack which is a bug with via vt6306 cards in OHCI 1.0 cards. >>> Oh, there's definitely more than one problem left... :) >>>> Further analysis of the problem has learned that this is not true, I'm >>>> using a via vt6306 card in OHCI 1.1 mode, which allegedly should work fine. >>> The particular bug is actually related to vt6306 and vt6307 cards in OHCI 1.0 >>> mode doing dv capture. iidc is much less tested. I already know where at least >>> a few of the iidc-related OHCI 1.0 bugs are, but they shouldn't be impacting >>> you... I've also got an idea or two on what's up with dv capture, just need to >>> get the spare cycles to test (which could happen shortly, just finished a >>> major piece of lirc...) >>>> However most documents talk about using the juju stack with either >>>> harddisks or DV for homevideo camera's. However I'm trying to use an >>>> industrial cam which used the IIDC protocol, and support in the new juju >>>> stack (kernel + userspace) for the IIDC protocol isn't very good. >>> I believe David Moore's patch in linux1394-2.6.git[*] should help, and it >>> looks like that also needs to be ported over to the OHCI 1.0 code paths... >> Nope, looks like he's already done that too. As I said in another thread, I'm >> going to try to start tracking the linux1394 git tree in rawhide, and >> selectively pull back patches into released kernels. David's done a lot of >> excellent work of late while I was busy not paying attention, due to the >> holidays and other misc stuff (lirc, ia64 xen, ecryptfs, ext4...) > > After a bit of positive testing, I committed a linux1394 git patch plus > David's dynamic buffer alloc patch, which is about to be in linux1394 git, to > the rawhide kernel. We've now got working iidc streaming on all OHCI 1.0 and > 1.1 cards, so far as I know. I'll see about back-porting these bits to the F7 > and F8 kernels as well. > > Would definitely like to hear what *doesn't* work now, short of dv capture > with Via VT630x OHCI 1.0 cards, which is known broken and under investigation. > Excellent keep up to good work! Regards, Hans From editora at cerebroecomunicacao.com.br Sat Jan 12 06:02:01 2008 From: editora at cerebroecomunicacao.com.br (Cérebro & Comunicação - Desenvolvimento Pessoal) Date: Sat, 12 Jan 2008 06:02:01 GMT Subject: =?iso-8859-1?q?curso_de_Controle_Mental=3A_apostila_+_3_CD=B4s?= =?iso-8859-1?q?=2E?= Message-ID: <200801131349.m0DDnBoF003520@mx3.redhat.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: frase_02.gif Type: image/gif Size: 2880 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: img_logo_chat.gif Type: image/gif Size: 9049 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: img_newsletter2.gif Type: image/gif Size: 13753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: yellow.gif Type: image/gif Size: 1292 bytes Desc: not available URL: From littletux at zarb.org Mon Jan 14 09:40:45 2008 From: littletux at zarb.org (Guillaume Bedot) Date: Mon, 14 Jan 2008 10:40:45 +0100 Subject: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix) In-Reply-To: <4787CE08.5000304@hhs.nl> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> <4787CE08.5000304@hhs.nl> Message-ID: <1200303645.11301.15.camel@littletux> Hello, On ven, 2008-01-11 at 21:14 +0100, Hans de Goede wrote: > Boaz Harrosh wrote: > > Yes, you're right. in ULDs it is a much proper way to do this. > > > > So I guess you'll have to do that special host flag or device > > flag, and add a check for it in sd.c. You'll see that sd.c is > > already doing bufflen truncation at sd_prep_fn(), just add one > > more case. > > > > Done, thanks for the hint. Patch implementing my fix this way attached, please > apply. > > Thanks & Regards, > > Hans > I have tested this time with two PSC 1610 printers, and two SD cards, the same bug occured without the patch. And is fixed with your new patch. ?Good work ! The bug however did not occur with a microSD card in a SD adaptator ?! But it fixes only two models. Do you think other devices (hp or not) can be impacted ? There are hundreds of models with card readers only for hp : http://hplip.sourceforge.net/supported_devices/combined.html Will this be possible to use "LAST_SECTOR_BUG" quirk for testing without recompiling a kernel ? Best regards, Guillaume B. From j.w.r.degoede at hhs.nl Mon Jan 14 09:46:56 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 14 Jan 2008 10:46:56 +0100 Subject: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix) In-Reply-To: <1200303645.11301.15.camel@littletux> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> <4787CE08.5000304@hhs.nl> <1200303645.11301.15.camel@littletux> Message-ID: <478B2F90.7010105@hhs.nl> Guillaume Bedot wrote: > I have tested this time with two PSC 1610 printers, and two SD cards, > the same bug occured without the patch. > And is fixed with your new patch. ?Good work ! > Hi, Thanks for testing! > But it fixes only two models. > Do you think other devices (hp or not) can be impacted ? > There are hundreds of models with card readers only for hp : > http://hplip.sourceforge.net/supported_devices/combined.html > > Will this be possible to use "LAST_SECTOR_BUG" quirk for testing without > recompiling a kernel ? > This is not possible AFAIK, I've already wrote a blog post about this asking for people to test this, but got no responses. I think it would be good if the people from the hplip project would take some time to test all the printer models they have got access too. Regards, Hans From mdharm-scsi at one-eyed-alien.net Mon Jan 14 16:03:10 2008 From: mdharm-scsi at one-eyed-alien.net (Matthew Dharm) Date: Mon, 14 Jan 2008 08:03:10 -0800 Subject: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix) In-Reply-To: <478B2F90.7010105@hhs.nl> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> <4787CE08.5000304@hhs.nl> <1200303645.11301.15.camel@littletux> <478B2F90.7010105@hhs.nl> Message-ID: <20080114160310.GH14375@one-eyed-alien.net> On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote: > Guillaume Bedot wrote: > >But it fixes only two models. > >Do you think other devices (hp or not) can be impacted ? > >There are hundreds of models with card readers only for hp : > >http://hplip.sourceforge.net/supported_devices/combined.html > > > >Will this be possible to use "LAST_SECTOR_BUG" quirk for testing without > >recompiling a kernel ? > > > > This is not possible AFAIK, I've already wrote a blog post about this > asking for people to test this, but got no responses. Once the patches are accepted by the SCSI people, one of the things we can consider doing is enabling this quirk for all USB devices. It should be pretty harmless to all properly working devices, and the performance hit should be pretty minimal. We may be able to convince the SCSI people to enable it for all devices, regardless of HCD. Matt -- Matthew Dharm Home: mdharm-usb at one-eyed-alien.net Maintainer, Linux USB Mass Storage Driver What the hell are you? -- Pitr to Dust Puppy User Friendly, 12/3/1997 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From James.Bottomley at HansenPartnership.com Mon Jan 14 16:33:08 2008 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Mon, 14 Jan 2008 10:33:08 -0600 Subject: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix) In-Reply-To: <20080114160310.GH14375@one-eyed-alien.net> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> <4787CE08.5000304@hhs.nl> <1200303645.11301.15.camel@littletux> <478B2F90.7010105@hhs.nl> <20080114160310.GH14375@one-eyed-alien.net> Message-ID: <1200328388.3159.20.camel@localhost.localdomain> On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote: > On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote: > > Guillaume Bedot wrote: > > >But it fixes only two models. > > >Do you think other devices (hp or not) can be impacted ? > > >There are hundreds of models with card readers only for hp : > > >http://hplip.sourceforge.net/supported_devices/combined.html > > > > > >Will this be possible to use "LAST_SECTOR_BUG" quirk for testing without > > >recompiling a kernel ? > > > > > > > This is not possible AFAIK, I've already wrote a blog post about this > > asking for people to test this, but got no responses. > > Once the patches are accepted by the SCSI people, one of the things we can > consider doing is enabling this quirk for all USB devices. It should be > pretty harmless to all properly working devices, and the performance hit > should be pretty minimal. The SCSI patches look OK, with the stylistic points fixed below ... we'll need two separate patches as well (one for SCSI, one for USB). > We may be able to convince the SCSI people to enable it for all devices, > regardless of HCD. No ... I'm not particularly keen to have enterprise vendors after my blood ... > + /* Some devices (some sdcards for one) don't like it if the last sector > + gets read in a larger then 1 sector read */ The comment style in sd is /* * comment */ > + if (sdp->last_sector_bug && rq->nr_sectors > sdp->sector_size / 512 && An unlikely() here, please to force the compiler to optimise for the non-buggy case. Plus what is the rq->nr_sectors > sdp->sector_size / 512 test supposed to be doing? that being true is supposed to be a guarantee of the block layer (and if something goes wrong there's a check for this lower down). > + block + rq->nr_sectors == get_capacity(disk)) { rq->nr_sectors should be this_count > + this_count -= sdp->sector_size / 512; If you relocate this code to after the sector_size/this_count adjustment code (i.e. about line 442) you can just do --this_count; James From j.w.r.degoede at hhs.nl Mon Jan 14 18:37:36 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 14 Jan 2008 19:37:36 +0100 Subject: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix) In-Reply-To: <1200328388.3159.20.camel@localhost.localdomain> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> <4787CE08.5000304@hhs.nl> <1200303645.11301.15.camel@littletux> <478B2F90.7010105@hhs.nl> <20080114160310.GH14375@one-eyed-alien.net> <1200328388.3159.20.camel@localhost.localdomain> Message-ID: <478BABF0.1040403@hhs.nl> James Bottomley wrote: > On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote: >> On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote: >>> Guillaume Bedot wrote: >>>> But it fixes only two models. >>>> Do you think other devices (hp or not) can be impacted ? >>>> There are hundreds of models with card readers only for hp : >>>> http://hplip.sourceforge.net/supported_devices/combined.html >>>> >>>> Will this be possible to use "LAST_SECTOR_BUG" quirk for testing without >>>> recompiling a kernel ? >>>> >>> This is not possible AFAIK, I've already wrote a blog post about this >>> asking for people to test this, but got no responses. >> Once the patches are accepted by the SCSI people, one of the things we can >> consider doing is enabling this quirk for all USB devices. It should be >> pretty harmless to all properly working devices, and the performance hit >> should be pretty minimal. > > The SCSI patches look OK, with the stylistic points fixed below ... > we'll need two separate patches as well (one for SCSI, one for USB). > Okay, Thanks for the review! I'll do a new scsi changes only patch once I get an answer to some questions regarding your review. >> + /* Some devices (some sdcards for one) don't like it if the last sector >> + gets read in a larger then 1 sector read */ > > The comment style in sd is > > /* > * comment > */ > Will fix, >> + if (sdp->last_sector_bug && rq->nr_sectors > sdp->sector_size / 512 && > > An unlikely() here, please to force the compiler to optimise for the > non-buggy case. Will do. > Plus what is the rq->nr_sectors > sdp->sector_size / > 512 test supposed to be doing? that being true is supposed to be a > guarantee of the block layer (and if something goes wrong there's a > check for this lower down). > It first is was just: rq->nr_sectors > 1 Then I changed it to also do the right thing for 1024 and larger sector disks. The whole purpose is to not read the last sector in a larger then one sector read, so the amount of sectors gets reduced by one if (block + rq->nr_sectors == get_capacity(disk)) but we do want still want to be able to read the last sector by itself, so we must not reduce the no sectors to be read by one if it is already one. >> + block + rq->nr_sectors == get_capacity(disk)) { > > rq->nr_sectors should be this_count > Fine by me, but in this place in the code they are the same value, and the check for a read beyond the end of disk a few lines above also uses rq->nr_sectors, which one should be used when? >> + this_count -= sdp->sector_size / 512; > > If you relocate this code to after the sector_size/this_count adjustment > code (i.e. about line 442) you can just do --this_count; > I cannot move the check down as then block has been adjusted for the sector size, so if I move the check down it becomes: if (block * (sdp->sector_size / 512) + rq->nr_sectors == get_capacity(disk)) I would rather not have the sdp->sector_size / 512 code in the check (slow) but rather in the not often entered if block. Regards, Hans From stefanr at s5r6.in-berlin.de Mon Jan 14 18:40:01 2008 From: stefanr at s5r6.in-berlin.de (Stefan Richter) Date: Mon, 14 Jan 2008 19:40:01 +0100 Subject: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix) In-Reply-To: <1200328388.3159.20.camel@localhost.localdomain> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> <4787CE08.5000304@hhs.nl> <1200303645.11301.15.camel@littletux> <478B2F90.7010105@hhs.nl> <20080114160310.GH14375@one-eyed-alien.net> <1200328388.3159.20.camel@localhost.localdomain> Message-ID: <478BAC81.2080101@s5r6.in-berlin.de> James Bottomley wrote: > On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote: >> On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote: >> > Guillaume Bedot wrote: >> > >Will this be possible to use "LAST_SECTOR_BUG" quirk for testing without >> > >recompiling a kernel ? >> > >> > This is not possible AFAIK, I've already wrote a blog post about this >> > asking for people to test this, but got no responses. >> >> Once the patches are accepted by the SCSI people, one of the things we can >> consider doing is enabling this quirk for all USB devices. ... >> We may be able to convince the SCSI people to enable it for all devices, >> regardless of HCD. > > No ... I'm not particularly keen to have enterprise vendors after my > blood ... Guillaume, you can tell the SCSI core driver at boot time (or module insertion time) and/or at runtime to - switch on default quirk flags, - add quirk flags for selected devices per name matching. Alas I don't know of a good documention how to do either of this, and I am not familiar enough with the procedure to explain it here. -- Stefan Richter -=====-==--- ---= -===- http://arcgraph.de/sr/ From mdharm-scsi at one-eyed-alien.net Mon Jan 14 19:01:05 2008 From: mdharm-scsi at one-eyed-alien.net (Matthew Dharm) Date: Mon, 14 Jan 2008 11:01:05 -0800 Subject: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix) In-Reply-To: <1200328388.3159.20.camel@localhost.localdomain> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> <4787CE08.5000304@hhs.nl> <1200303645.11301.15.camel@littletux> <478B2F90.7010105@hhs.nl> <20080114160310.GH14375@one-eyed-alien.net> <1200328388.3159.20.camel@localhost.localdomain> Message-ID: <20080114190105.GJ14375@one-eyed-alien.net> On Mon, Jan 14, 2008 at 10:33:08AM -0600, James Bottomley wrote: > > On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote: > > We may be able to convince the SCSI people to enable it for all devices, > > regardless of HCD. > > No ... I'm not particularly keen to have enterprise vendors after my > blood ... Fair enough. Tho, we should probably just enable this blindly for all usb-storage devices. Otherwise, this is just going to become an unusual_devs.h nightmare. Matt -- Matthew Dharm Home: mdharm-usb at one-eyed-alien.net Maintainer, Linux USB Mass Storage Driver What, are you one of those Microsoft-bashing Linux freaks? -- Customer to Greg User Friendly, 2/10/1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From James.Bottomley at HansenPartnership.com Mon Jan 14 19:09:18 2008 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Mon, 14 Jan 2008 13:09:18 -0600 Subject: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix) In-Reply-To: <478BABF0.1040403@hhs.nl> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> <4787CE08.5000304@hhs.nl> <1200303645.11301.15.camel@littletux> <478B2F90.7010105@hhs.nl> <20080114160310.GH14375@one-eyed-alien.net> <1200328388.3159.20.camel@localhost.localdomain> <478BABF0.1040403@hhs.nl> Message-ID: <1200337759.3159.58.camel@localhost.localdomain> On Mon, 2008-01-14 at 19:37 +0100, Hans de Goede wrote: > James Bottomley wrote: > > On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote: > >> On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote: > >>> Guillaume Bedot wrote: > >>>> But it fixes only two models. > >>>> Do you think other devices (hp or not) can be impacted ? > >>>> There are hundreds of models with card readers only for hp : > >>>> http://hplip.sourceforge.net/supported_devices/combined.html > >>>> > >>>> Will this be possible to use "LAST_SECTOR_BUG" quirk for testing without > >>>> recompiling a kernel ? > >>>> > >>> This is not possible AFAIK, I've already wrote a blog post about this > >>> asking for people to test this, but got no responses. > >> Once the patches are accepted by the SCSI people, one of the things we can > >> consider doing is enabling this quirk for all USB devices. It should be > >> pretty harmless to all properly working devices, and the performance hit > >> should be pretty minimal. > > > > The SCSI patches look OK, with the stylistic points fixed below ... > > we'll need two separate patches as well (one for SCSI, one for USB). > > > > Okay, > > Thanks for the review! I'll do a new scsi changes only patch once I get an > answer to some questions regarding your review. > > >> + /* Some devices (some sdcards for one) don't like it if the last sector > >> + gets read in a larger then 1 sector read */ > > > > The comment style in sd is > > > > /* > > * comment > > */ > > > > Will fix, > > >> + if (sdp->last_sector_bug && rq->nr_sectors > sdp->sector_size / 512 && > > > > An unlikely() here, please to force the compiler to optimise for the > > non-buggy case. > > Will do. > > > Plus what is the rq->nr_sectors > sdp->sector_size / > > 512 test supposed to be doing? that being true is supposed to be a > > guarantee of the block layer (and if something goes wrong there's a > > check for this lower down). > > > > It first is was just: > rq->nr_sectors > 1 > > Then I changed it to also do the right thing for 1024 and larger sector disks. > The whole purpose is to not read the last sector in a larger then one sector > read, so the amount of sectors gets reduced by one if (block + rq->nr_sectors > == get_capacity(disk)) but we do want still want to be able to read the last > sector by itself, so we must not reduce the no sectors to be read by one if it > is already one. Yes, I know that. What I mean is the block subsystem sends reads and writes down in increments of the sector size. Checking if the current number of pending sectors is greater than the current block size is checking that guarantee. The current code already has a check in it to see if this guarantee is observed ... you don't need to check it again. > >> + block + rq->nr_sectors == get_capacity(disk)) { > > > > rq->nr_sectors should be this_count > > > > Fine by me, but in this place in the code they are the same value, and the > check for a read beyond the end of disk a few lines above also uses > rq->nr_sectors, which one should be used when? this_count is the adjusted sector size. At the moment, there's no size transformation in the code between your check and the top (where this_count is set to rq->nr_sectors). But if there were (and someone might add one one day) you'd be wanting to check the adjusted size (i.e. this_count). > >> + this_count -= sdp->sector_size / 512; > > > > If you relocate this code to after the sector_size/this_count adjustment > > code (i.e. about line 442) you can just do --this_count; > > > > I cannot move the check down as then block has been adjusted for the sector > size, so if I move the check down it becomes: > if (block * (sdp->sector_size / 512) + rq->nr_sectors == get_capacity(disk)) > > I would rather not have the sdp->sector_size / 512 code in the check (slow) but > rather in the not often entered if block. OK, point taken, it would be worse. I think today's compilers are happy to translate x/512 to x>>9, so it shouldn't be that slow. James From j.w.r.degoede at hhs.nl Mon Jan 14 19:10:59 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 14 Jan 2008 20:10:59 +0100 Subject: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix) In-Reply-To: <20080114190105.GJ14375@one-eyed-alien.net> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> <4787CE08.5000304@hhs.nl> <1200303645.11301.15.camel@littletux> <478B2F90.7010105@hhs.nl> <20080114160310.GH14375@one-eyed-alien.net> <1200328388.3159.20.camel@localhost.localdomain> <20080114190105.GJ14375@one-eyed-alien.net> Message-ID: <478BB3C3.3070101@hhs.nl> Matthew Dharm wrote: > On Mon, Jan 14, 2008 at 10:33:08AM -0600, James Bottomley wrote: >> On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote: >>> We may be able to convince the SCSI people to enable it for all devices, >>> regardless of HCD. >> No ... I'm not particularly keen to have enterprise vendors after my >> blood ... > > Fair enough. Tho, we should probably just enable this blindly for all > usb-storage devices. Otherwise, this is just going to become an > unusual_devs.h nightmare. > Since this will make all devices with this bug "just work" (tm), I'm all for it! As soon as I get an answer from the scsi people on my questions resulting from there review I'll do a new patch for the scsi layer for this. Regards, Hans From j.w.r.degoede at hhs.nl Mon Jan 14 19:27:17 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 14 Jan 2008 20:27:17 +0100 Subject: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix) In-Reply-To: <1200337759.3159.58.camel@localhost.localdomain> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> <4787CE08.5000304@hhs.nl> <1200303645.11301.15.camel@littletux> <478B2F90.7010105@hhs.nl> <20080114160310.GH14375@one-eyed-alien.net> <1200328388.3159.20.camel@localhost.localdomain> <478BABF0.1040403@hhs.nl> <1200337759.3159.58.camel@localhost.localdomain> Message-ID: <478BB795.4040305@hhs.nl> James Bottomley wrote: >>> Plus what is the rq->nr_sectors > sdp->sector_size / >>> 512 test supposed to be doing? that being true is supposed to be a >>> guarantee of the block layer (and if something goes wrong there's a >>> check for this lower down). >>> >> It first is was just: >> rq->nr_sectors > 1 >> >> Then I changed it to also do the right thing for 1024 and larger sector disks. >> The whole purpose is to not read the last sector in a larger then one sector >> read, so the amount of sectors gets reduced by one if (block + rq->nr_sectors >> == get_capacity(disk)) but we do want still want to be able to read the last >> sector by itself, so we must not reduce the no sectors to be read by one if it >> is already one. > > Yes, I know that. What I mean is the block subsystem sends reads and > writes down in increments of the sector size. Checking if the current > number of pending sectors is greater than the current block size is > checking that guarantee. The current code already has a check in it to > see if this guarantee is observed ... you don't need to check it again. > I'm not checking for the guarantee, I'm checking that the read > 1 realsize_sector, before decrementing the number of _512_bytes_sectors by realsize_sector, this check must be there, as after reading all but the last sector, another request will be send with 1 realsize_sector size, for which (block + rq->nr_sectors) == get_capacity(disk) will still hold true, in this case this_count must not be lowered, otherwise this_count will become 0 in this case and the last sector will never get read. I hope that clarifies why that code is there, if not can you tell how you would want the code to look by just giving the full if statement as it should be, I think we are somehow misunderstanding each other. Regards, Hans From James.Bottomley at HansenPartnership.com Mon Jan 14 20:20:46 2008 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Mon, 14 Jan 2008 14:20:46 -0600 Subject: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix) In-Reply-To: <478BB795.4040305@hhs.nl> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> <4787CE08.5000304@hhs.nl> <1200303645.11301.15.camel@littletux> <478B2F90.7010105@hhs.nl> <20080114160310.GH14375@one-eyed-alien.net> <1200328388.3159.20.camel@localhost.localdomain> <478BABF0.1040403@hhs.nl> <1200337759.3159.58.camel@localhost.localdomain> <478BB795.4040305@hhs.nl> Message-ID: <1200342046.3159.64.camel@localhost.localdomain> On Mon, 2008-01-14 at 20:27 +0100, Hans de Goede wrote: > James Bottomley wrote: > >>> Plus what is the rq->nr_sectors > sdp->sector_size / > >>> 512 test supposed to be doing? that being true is supposed to be a > >>> guarantee of the block layer (and if something goes wrong there's a > >>> check for this lower down). > >>> > >> It first is was just: > >> rq->nr_sectors > 1 > >> > >> Then I changed it to also do the right thing for 1024 and larger sector disks. > >> The whole purpose is to not read the last sector in a larger then one sector > >> read, so the amount of sectors gets reduced by one if (block + rq->nr_sectors > >> == get_capacity(disk)) but we do want still want to be able to read the last > >> sector by itself, so we must not reduce the no sectors to be read by one if it > >> is already one. > > > > Yes, I know that. What I mean is the block subsystem sends reads and > > writes down in increments of the sector size. Checking if the current > > number of pending sectors is greater than the current block size is > > checking that guarantee. The current code already has a check in it to > > see if this guarantee is observed ... you don't need to check it again. > > > > I'm not checking for the guarantee, I'm checking that the read > 1 > realsize_sector, before decrementing the number of _512_bytes_sectors by > realsize_sector, this check must be there, as after reading all but the last > sector, another request will be send with 1 realsize_sector size, for which > (block + rq->nr_sectors) == get_capacity(disk) will still hold true, in this > case this_count must not be lowered, otherwise this_count will become 0 in this > case and the last sector will never get read. > > I hope that clarifies why that code is there, if not can you tell how you would > want the code to look by just giving the full if statement as it should be, I > think we are somehow misunderstanding each other. Oh, right; it's > rather than >= ... sorry, yes that's fine. James From SWISSLOTTO at ONLINEGAMES.ORG Tue Jan 15 22:48:10 2008 From: SWISSLOTTO at ONLINEGAMES.ORG (SWISSLOTTO PROMOTIONS) Date: Tue, 15 Jan 2008 16:48:10 -0600 Subject: !*Internet Emails Award Call Your Claims Agent (Mr Luis Johnson)*! Message-ID: <200801152248.m0FMmAA0004460@web219.opentransfer.com> SWISS-LOTTO NETHERLANDS Palistrinalaan 44, 8011vn, Zwolle Netherlands https://www.swisslotto.ch !!!CONGRATULATION YOU ARE A WINNER!!!. The Board of Directors, members of staff and the International Promotion Department of the SWISS-LOTTO Satellite lottery, Netherlands, wishes to congratulate you on your success as the STAR PRIZE WINNER in this years' SWISS-LOTTO Satellite lottery Netherlands International Promotion (SLP) .The late notice was due to mix up email addresses, no tickets were sold, and you were randomly selected as a winner. This comes with a prize of Seven Hundred and Fifty Thousand Euro (?750,000) Euros in the SWISS-LOTTO Satellite Software email lottery in which e-mail addresses are picked randomly by Software powered by the Internet through the worldwide website. Your email address was amongst those chosen this year for the SWISS-LOTTO Satellite lottery. And this promotion is proudly sponsored by the SWISS-LOTTO NETHERLANDS organization. The selection process was carried out through random selection in our Computerized Email Selection System (C.E.S.S.) from a database of over a million email addresses from the World Wide Web. Each email address was attached to a ticket number and your email address with ticket number: KY/098/HG/7BN was randomly selected as the star prize winner amongst other consolation prize winners. Your email address, attached to Ref number 18, 43, 5, 7, 14, 17 with Serial number SLN/2378-32 drew the lucky Numbers 56, and consequently won the lottery in the "A" Category. You have therefore been approved for a lump sum pay out of ? 750,000 Euros.( Seven Hundred and Fifty Thousand Euros). Please note that your lucky winning number falls within our European Booklet representative office in Europe as indicated in your play coupon. In View of this, your ? 750,000 Euros will be released to you by our accredited claims agent located in Europe. Our European agent will immediately commence the process to facilitate the release of your winning funds as soon as you contact them. To file for your claim, kindly fill the verification form below and send it to the accredited Claims Manager, Mr. Luis Johnson of the claims department through email, stating your receipt of this notification. He has been mandated to offer you assistance and facilitate the urgent delivery of your prizes. Provide our/your accredited claims agent with the information as stated below: Mr. Luis Johnson Tel: +31619705470 Fax:+31847597673 Email: fidiciaryagents at aol.nl VERIFICATION FORM: 1.) FULL NAME: 2.) AGE: 3.) SEX: 4.) MARITAL STATUS: 5.) ADDRESS: 6.) DRAW NUMBER ABOVE: 7.) OCCUPATION: 8.) COUNTRY OF RESIDENT: 9.) NATIONALITY: 10.) PHONE: 11.) FAX NUMBER: Thanks for been part of this promotional award programm.We wish you the best of lucky as you spend your good fortune. Sincerely, Hans William SWISS-LOTTO NETHERLANDS. Palistrinalaan 44, 8011vn, Zwolle Netherlands https://www.swisslotto.ch N.B: Keep all lotto information from public to avoid double claims, as any breach of confidentiality on the part of the winners will result to disqualification. From jwboyer at gmail.com Wed Jan 16 03:01:32 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 15 Jan 2008 21:01:32 -0600 Subject: PowerPC config options Message-ID: <20080115210132.79b8f107@vader.jdub.homelinux.org> Couple of PowerPC related config things we might want to change. 1) CONFIG_TUNE_CELL. Right now, this is set to Y on config-powerpc64. That's fine only because it doesn't do anything until GCC 4.3 shows up. GCC 4.3 will hit rawhide soon, and we might want to turn this off before then or the kernel will likely run slower on non-Cell CPU based machines. 2) Why are we still building a separate powerpc32-smp kernel? SMP kernel's work on UP machines, even for PowerPC IIRC. josh From office at alphafinancialconsult.co.uk Wed Jan 16 05:45:54 2008 From: office at alphafinancialconsult.co.uk (ALPHA FINANCIAL CONSULT) Date: Wed, 16 Jan 2008 06:45:54 +0100 Subject: FUNDS CONSULTATION 2 Message-ID: From: ALPHA FINANCIAL CONSULT. LONDON, U.K. We wish to notify you again that you were listed as a beneficiary to the total sum of ?6,000,000.00 GBP (Six Million British Pounds) in the codicil and last testament of the deceased. (Name now withheld since this is our second letter to you). We contacted you because you bear the surname identity and therefore can present you as the beneficiary to the inheritance. We therefore reckoned that you could receive these funds as you are qualified by your name identity. All the legal papers will be processed upon your acceptance. Upon your acceptance of this deal, we request that you kindly forward to us your letter of acceptance, your current telephone and fax numbers and a forwarding address to enable us file necessary LEGAL documents in your name at our high court probate division for the release of the fund in question. Please contact me ASAP by e-mail and call: +447024058242. so that we can get this done immediately. Kind regards, Allen Stone. Direct Line: +447024058242. Email: allenstn at mixmail.com From dwmw2 at infradead.org Wed Jan 16 14:23:49 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 16 Jan 2008 22:23:49 +0800 Subject: PowerPC config options In-Reply-To: <20080115210132.79b8f107@vader.jdub.homelinux.org> References: <20080115210132.79b8f107@vader.jdub.homelinux.org> Message-ID: <1200493429.9191.21.camel@shinybook.infradead.org> On Tue, 2008-01-15 at 21:01 -0600, Josh Boyer wrote: > Couple of PowerPC related config things we might want to change. > > 1) CONFIG_TUNE_CELL. Right now, this is set to Y on config-powerpc64. > That's fine only because it doesn't do anything until GCC 4.3 shows > up. GCC 4.3 will hit rawhide soon, and we might want to turn this off > before then or the kernel will likely run slower on non-Cell CPU based > machines. Will do. I'd wondered about that myself quite recently -- not sure who turned it on. > 2) Why are we still building a separate powerpc32-smp kernel? SMP > kernel's work on UP machines, even for PowerPC IIRC. But not particularly efficiently, and _most_ ppc32 machines are UP. For i386 SMP we have magic to NOP out the spinlocks, etc. -- dwmw2 From mra at hp.com Thu Jan 17 23:49:51 2008 From: mra at hp.com (Matt Anderson) Date: Thu, 17 Jan 2008 18:49:51 -0500 Subject: tpm_infineon=m for config-ia64 Message-ID: <478FE99F.8050606@hp.com> I noticed that config-x86 and config-x86_64 both have tpm_infineon=m but config-ia64 does not. I enabled that on my system and rebuild the kernel rpm and everything just worked. Could tpm_infineon be built as a module by default for ia64? Thanks -matt From kyle at mcmartin.ca Thu Jan 17 23:59:05 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Thu, 17 Jan 2008 18:59:05 -0500 Subject: tpm_infineon=m for config-ia64 In-Reply-To: <478FE99F.8050606@hp.com> References: <478FE99F.8050606@hp.com> Message-ID: <20080117235905.GC21681@phobos.i.cabal.ca> On Thu, Jan 17, 2008 at 06:49:51PM -0500, Matt Anderson wrote: > I noticed that config-x86 and config-x86_64 both have tpm_infineon=m but > config-ia64 does not. I enabled that on my system and rebuild the kernel > rpm and everything just worked. Could tpm_infineon be built as a module by > default for ia64? > er, sure, i guess. cheers, Kyle From davej at redhat.com Fri Jan 18 01:27:01 2008 From: davej at redhat.com (Dave Jones) Date: Thu, 17 Jan 2008 20:27:01 -0500 Subject: tpm_infineon=m for config-ia64 In-Reply-To: <20080117235905.GC21681@phobos.i.cabal.ca> References: <478FE99F.8050606@hp.com> <20080117235905.GC21681@phobos.i.cabal.ca> Message-ID: <20080118012701.GA28393@redhat.com> On Thu, Jan 17, 2008 at 06:59:05PM -0500, Kyle McMartin wrote: > On Thu, Jan 17, 2008 at 06:49:51PM -0500, Matt Anderson wrote: > > I noticed that config-x86 and config-x86_64 both have tpm_infineon=m but > > config-ia64 does not. I enabled that on my system and rebuild the kernel > > rpm and everything just worked. Could tpm_infineon be built as a module by > > default for ia64? > > > > er, sure, i guess. No objection either, though it's worth noting that there's no userspace support in Fedora for any of the TPM kernel stuff. Dave -- http://www.codemonkey.org.uk From jwilson at redhat.com Fri Jan 18 01:43:37 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 17 Jan 2008 20:43:37 -0500 Subject: tpm_infineon=m for config-ia64 In-Reply-To: <20080118012701.GA28393@redhat.com> References: <478FE99F.8050606@hp.com> <20080117235905.GC21681@phobos.i.cabal.ca> <20080118012701.GA28393@redhat.com> Message-ID: <47900449.6020604@redhat.com> Dave Jones wrote: > On Thu, Jan 17, 2008 at 06:59:05PM -0500, Kyle McMartin wrote: > > On Thu, Jan 17, 2008 at 06:49:51PM -0500, Matt Anderson wrote: > > > I noticed that config-x86 and config-x86_64 both have tpm_infineon=m but > > > config-ia64 does not. I enabled that on my system and rebuild the kernel > > > rpm and everything just worked. Could tpm_infineon be built as a module by > > > default for ia64? > > > > > > > er, sure, i guess. > > No objection either, though it's worth noting that there's no userspace > support in Fedora for any of the TPM kernel stuff. However, I believe trousers has been submitted for fedora review, and was close to being accepted if it hasn't been already. -- Jarod Wilson jwilson at redhat.com From notting at redhat.com Fri Jan 18 02:17:48 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 17 Jan 2008 21:17:48 -0500 Subject: tpm_infineon=m for config-ia64 In-Reply-To: <20080118012701.GA28393@redhat.com> References: <478FE99F.8050606@hp.com> <20080117235905.GC21681@phobos.i.cabal.ca> <20080118012701.GA28393@redhat.com> Message-ID: <20080118021748.GB414@nostromo.devel.redhat.com> Dave Jones (davej at redhat.com) said: > No objection either, though it's worth noting that there's no userspace > support in Fedora for any of the TPM kernel stuff. It's there in rawhide (tpm_tools, trousers) Bill From e.blackburnnx at magma.ca Fri Jan 18 11:16:18 2008 From: e.blackburnnx at magma.ca (e.blackburnnx at magma.ca) Date: Fri, 18 Jan 2008 12:16:18 +0100 Subject: Magic Power Of Love Message-ID: <47908A82.4080204@magma.ca> Your Friend and Lover http://98.200.125.78/ From mra at hp.com Fri Jan 18 21:42:36 2008 From: mra at hp.com (Matt Anderson) Date: Fri, 18 Jan 2008 16:42:36 -0500 Subject: tpm_infineon=m for config-ia64 In-Reply-To: <20080118021748.GB414@nostromo.devel.redhat.com> References: <478FE99F.8050606@hp.com> <20080117235905.GC21681@phobos.i.cabal.ca> <20080118012701.GA28393@redhat.com> <20080118021748.GB414@nostromo.devel.redhat.com> Message-ID: <47911D4C.5070201@hp.com> Bill Nottingham wrote: > Dave Jones (davej at redhat.com) said: >> No objection either, though it's worth noting that there's no userspace >> support in Fedora for any of the TPM kernel stuff. > > It's there in rawhide (tpm_tools, trousers) So is this something that can just be enabled, or would you like me to open a bugzilla for this? -matt From jwilson at redhat.com Fri Jan 18 21:53:40 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 18 Jan 2008 16:53:40 -0500 Subject: tpm_infineon=m for config-ia64 In-Reply-To: <47911D4C.5070201@hp.com> References: <478FE99F.8050606@hp.com> <20080117235905.GC21681@phobos.i.cabal.ca> <20080118012701.GA28393@redhat.com> <20080118021748.GB414@nostromo.devel.redhat.com> <47911D4C.5070201@hp.com> Message-ID: <47911FE4.9080507@redhat.com> Matt Anderson wrote: > Bill Nottingham wrote: >> Dave Jones (davej at redhat.com) said: >>> No objection either, though it's worth noting that there's no userspace >>> support in Fedora for any of the TPM kernel stuff. >> >> It's there in rawhide (tpm_tools, trousers) > > So is this something that can just be enabled, or would you like me to > open a bugzilla for this? Kyle already did it. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mra at hp.com Fri Jan 18 21:54:06 2008 From: mra at hp.com (Matt Anderson) Date: Fri, 18 Jan 2008 16:54:06 -0500 Subject: tpm_infineon=m for config-ia64 In-Reply-To: <47911FE4.9080507@redhat.com> References: <478FE99F.8050606@hp.com> <20080117235905.GC21681@phobos.i.cabal.ca> <20080118012701.GA28393@redhat.com> <20080118021748.GB414@nostromo.devel.redhat.com> <47911D4C.5070201@hp.com> <47911FE4.9080507@redhat.com> Message-ID: <47911FFE.5070502@hp.com> Jarod Wilson wrote: > Matt Anderson wrote: >> Bill Nottingham wrote: >>> Dave Jones (davej at redhat.com) said: >>>> No objection either, though it's worth noting that there's no userspace >>>> support in Fedora for any of the TPM kernel stuff. >>> It's there in rawhide (tpm_tools, trousers) >> So is this something that can just be enabled, or would you like me to >> open a bugzilla for this? > > Kyle already did it. You guys are awesome. From drago01 at gmail.com Sat Jan 19 11:11:16 2008 From: drago01 at gmail.com (drago01) Date: Sat, 19 Jan 2008 12:11:16 +0100 Subject: CONFIG_PHYSICAL_START Message-ID: <4791DAD4.8030009@gmail.com> Hi, I downloaded kernel-2.6.23.14-113.fc8 from koji and wanted to boot it on my NF4 SLI / Opteron 170 based box (x86_64) and the system reboots immediately when booting this kernel. I was using 2.6.23.12-99.fc8 before which is working fine. I suspect that this "Set x86 CONFIG_PHYSICAL_START=0x400000" change caused the breakage; currently I am downloading the srpm to verify that this indeed was causing it (the other changes look unreleated) before filling a bug. What was this supposed to fix/improve ? From drago01 at gmail.com Sat Jan 19 11:29:27 2008 From: drago01 at gmail.com (drago01) Date: Sat, 19 Jan 2008 12:29:27 +0100 Subject: CONFIG_PHYSICAL_START In-Reply-To: <4791DAD4.8030009@gmail.com> References: <4791DAD4.8030009@gmail.com> Message-ID: <4791DF17.7000806@gmail.com> drago01 wrote: > Hi, > I downloaded kernel-2.6.23.14-113.fc8 from koji and wanted to boot it > on my NF4 SLI / Opteron 170 based box (x86_64) and the system reboots > immediately when booting this kernel. > I was using 2.6.23.12-99.fc8 before which is working fine. > I suspect that this "Set x86 CONFIG_PHYSICAL_START=0x400000" change > caused the breakage; currently I am downloading the srpm to verify > that this indeed was causing it (the other changes look unreleated) > before filling a bug. > What was this supposed to fix/improve ? > OK, found the bug https://bugzilla.redhat.com/show_bug.cgi?id=309751 (was referenced from the F7 changelog). From miriamhuber25 at web.de Sat Jan 19 01:52:31 2008 From: miriamhuber25 at web.de (miriam) Date: Sat, 19 Jan 2008 02:52:31 +0100 Subject: Hallo nochmal Message-ID: <0e250bbf8ba212ce2ea8a878251139b1@web.de> Hallo super kostenloser online TV sender auf http://www.doenertreff.de ausserdem kannst du hier leute aus deiner umgebung kennenlernen http://adultfriendfinder.com/go/p409433 gruss From j.w.r.degoede at hhs.nl Sun Jan 20 10:12:16 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 20 Jan 2008 11:12:16 +0100 Subject: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix) In-Reply-To: <1200342046.3159.64.camel@localhost.localdomain> References: <47854051.1060307@hhs.nl> <4785F6CD.6050907@panasas.com> <4785F908.3080307@hhs.nl> <47860106.3090509@panasas.com> <4787CE08.5000304@hhs.nl> <1200303645.11301.15.camel@littletux> <478B2F90.7010105@hhs.nl> <20080114160310.GH14375@one-eyed-alien.net> <1200328388.3159.20.camel@localhost.localdomain> <478BABF0.1040403@hhs.nl> <1200337759.3159.58.camel@localhost.localdomain> <478BB795.4040305@hhs.nl> <1200342046.3159.64.camel@localhost.localdomain> Message-ID: <47931E80.6050207@hhs.nl> James Bottomley wrote: > On Mon, 2008-01-14 at 20:27 +0100, Hans de Goede wrote: >> James Bottomley wrote: >>>>> Plus what is the rq->nr_sectors > sdp->sector_size / >>>>> 512 test supposed to be doing? that being true is supposed to be a >>>>> guarantee of the block layer (and if something goes wrong there's a >>>>> check for this lower down). >>>>> >>>> It first is was just: >>>> rq->nr_sectors > 1 >>>> >>>> Then I changed it to also do the right thing for 1024 and larger sector disks. >>>> The whole purpose is to not read the last sector in a larger then one sector >>>> read, so the amount of sectors gets reduced by one if (block + rq->nr_sectors >>>> == get_capacity(disk)) but we do want still want to be able to read the last >>>> sector by itself, so we must not reduce the no sectors to be read by one if it >>>> is already one. >>> Yes, I know that. What I mean is the block subsystem sends reads and >>> writes down in increments of the sector size. Checking if the current >>> number of pending sectors is greater than the current block size is >>> checking that guarantee. The current code already has a check in it to >>> see if this guarantee is observed ... you don't need to check it again. >>> >> I'm not checking for the guarantee, I'm checking that the read > 1 >> realsize_sector, before decrementing the number of _512_bytes_sectors by >> realsize_sector, this check must be there, as after reading all but the last >> sector, another request will be send with 1 realsize_sector size, for which >> (block + rq->nr_sectors) == get_capacity(disk) will still hold true, in this >> case this_count must not be lowered, otherwise this_count will become 0 in this >> case and the last sector will never get read. >> >> I hope that clarifies why that code is there, if not can you tell how you would >> want the code to look by just giving the full if statement as it should be, I >> think we are somehow misunderstanding each other. > > Oh, right; it's > rather than >= ... sorry, yes that's fine. > Ok, I got swamped @work this week so it took a while, but I've made a new seperate (scsi-sd only) patch with the cleanups as discussed. I'm sending this (to the full recipient list) in a new top level post titled: PATCH: scsi-sd-last-sector-bug-flag.patch Regards, Hans From ClaudiaMeier74 at web.de Sat Jan 19 22:49:13 2008 From: ClaudiaMeier74 at web.de (meier claudia) Date: Sat, 19 Jan 2008 23:49:13 +0100 Subject: Hallo nochmal Message-ID: <68f9fee787704668ceabc5c917be9056@web.de> Hallo super kostenloser online TV sender auf http://www.doenertreff.de ausserdem kannst du hier leute aus deiner umgebung kennenlernen http://adultfriendfinder.com/go/g869222-pmo gruss From ajackson at redhat.com Mon Jan 21 22:22:56 2008 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 21 Jan 2008 17:22:56 -0500 Subject: RFC: Minor specfile rework for rawhide Message-ID: <1200954176.23041.7.camel@localhost.localdomain> http://people.freedesktop.org/~ajax/kernel-autopatch.patch Based on something I did for the xserver specfile. Essentially this makes it so you only have to name the patches once, in the order you want to apply them, which makes it both easier to work with and harder to forget things. I've tried to make this as friendly and robust as possible, including bailing out appropriately when faced with a bad patch, and explicitly naming patches that fail to apply right at the end of build output. Feedback would be appreciated, even if it's of the form "no, that's gross." - ajax From snecklifter at gmail.com Mon Jan 21 23:11:43 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 21 Jan 2008 23:11:43 +0000 Subject: RFC: Minor specfile rework for rawhide In-Reply-To: <1200954176.23041.7.camel@localhost.localdomain> References: <1200954176.23041.7.camel@localhost.localdomain> Message-ID: <364d303b0801211511v62bff389x16584e012b763719@mail.gmail.com> On 21/01/2008, Adam Jackson wrote: > http://people.freedesktop.org/~ajax/kernel-autopatch.patch > > Based on something I did for the xserver specfile. Essentially this > makes it so you only have to name the patches once, in the order you > want to apply them, which makes it both easier to work with and harder > to forget things. > > I've tried to make this as friendly and robust as possible, including > bailing out appropriately when faced with a bad patch, and explicitly > naming patches that fail to apply right at the end of build output. > Feedback would be appreciated, even if it's of the form "no, that's > gross." Can't speak from an implementation point of view but you must be a mind-reader. Several people will appreciate the thought behind it, myself included. On #fedora-kernel recently: i really find it irritating that i need to edit Patchxx: *and* add an ApplyPatch. * kylem ponders converting the spec file to use quilt. fark not a fan of that either why not j-rod ? I think he meant he's not a fan of editing twice. not that he wasn't a fan of quilt. oh i always forget to do one or the other :\ Cheers! -- Christopher Brown http://www.chruz.com From jwilson at redhat.com Tue Jan 22 04:20:17 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 21 Jan 2008 23:20:17 -0500 Subject: RFC: Minor specfile rework for rawhide In-Reply-To: <364d303b0801211511v62bff389x16584e012b763719@mail.gmail.com> References: <1200954176.23041.7.camel@localhost.localdomain> <364d303b0801211511v62bff389x16584e012b763719@mail.gmail.com> Message-ID: <47956F01.70400@redhat.com> Christopher Brown wrote: > On 21/01/2008, Adam Jackson wrote: >> http://people.freedesktop.org/~ajax/kernel-autopatch.patch >> >> Based on something I did for the xserver specfile. Essentially this >> makes it so you only have to name the patches once, in the order you >> want to apply them, which makes it both easier to work with and harder >> to forget things. >> >> I've tried to make this as friendly and robust as possible, including >> bailing out appropriately when faced with a bad patch, and explicitly >> naming patches that fail to apply right at the end of build output. >> Feedback would be appreciated, even if it's of the form "no, that's >> gross." > > Can't speak from an implementation point of view but you must be a > mind-reader. Several people will appreciate the thought behind it, > myself included. On #fedora-kernel recently: > > i really find it irritating that i need to edit Patchxx: *and* > add an ApplyPatch. > * kylem ponders converting the spec file to use quilt. > fark > not a fan of that either > why not j-rod ? > I think he meant he's not a fan of editing twice. > not that he wasn't a fan of quilt. > oh > i always forget to do one or the other :\ First glance says oh hell yeah, check it in. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From j.blaise70 at yahoo.com Tue Jan 22 14:35:42 2008 From: j.blaise70 at yahoo.com (Joyce Blaise) Date: 22 Jan 2008 06:35:42 -0800 Subject: ASSISTANCE NEEDED URGENTLY. Message-ID: <200801221536.m0MFP6e5000344@mx3.redhat.com> You are invited to "ASSISTANCE NEEDED URGENTLY.". By your host Joyce Blaise: Greetings, I am Joyce Blaise the only duaghter of late Mr. and Mrs. James Blaise My Father was a very wealthy cocoa merchant in Abidjan ,the economic capital of Ivory coast, My Father was poisoned to dearth by his business associates so now I am in a problems here in my country right now.Plz i am seeking for your urgent help to transfer US$10.5 millions into your bank account for investment purpose.15% is for your help.Contact me for more details.Email:blaisejoyce0 at mailbox.co.za J Blaise Date: Tuesday January 22, 2008 Time: 2:00 pm - 3:00 pm (GMT +00:00) Location: Reply Me On This ID: blaisejoyce0 at mailbox.co.za Guests: * fedora-legacy-list at redhat.com * fedora-ocaml-list at redhat.com * fedora-qa-list at redhat.com * fedora-package-review at redhat.com * fedora-kernel-list at redhat.com * fedora-relnotes-content at redhat.com * relnotes at fedoraproject.org * fedora-sparc at redhat.com * fedora-perl-devel-list at redhat.com * fedora-trans-hi at redhat.com * fedora-security-list at redhat.com * fedora-triage-list at redhat.com * fedora-trans-bn_in at redhat.com * fedora-trans-bg at redhat.com * gov-sec at redhat.com * func-list at redhat.com * fedora-trans-ar at redhat.com * guinness-list at redhat.com * freeipa-devel at redhat.com * fedora-trans-sr at redhat.com * hwcert-announce-list at redhat.com * jboss-security-beta at redhat.com * kickstart-list at redhat.com * libvir-list at redhat.com * veillard at redhat.com * k12ltsp-list at redhat.com * fedora-websites-list at redhat.com * lhcp-devel at redhat.com * linux-am33-list at redhat.com * jbosscc-external at redhat.com * ncsu-redhat-list at redhat.com * olpc-brasil at redhat.com * pam-list at redhat.com * olpc-vault-devel at redhat.com * perl-rpm-list at redhat.com * lohit-devel-list at redhat.com * -wg at redhat.com * linux-cluster at redhat.com * psyche-list at redhat.com * piranha-list at redhat.com * nahant-beta-list at redhat.com * java-info at redhat.com * pump-list at redhat.com * rhelv5-beta-list at redhat.com * redhat-secure-server at redhat.com * rh-barcap-list at redhat.com * rhh-discussion at redhat.com * rhel-support-list at redhat.com * redhat-list-de-owner at redhat.com * redhat-list-de at redhat.com * rhel-rt-sun at redhat.com * rhcc-outage-list at redhat.com * redhat-s390-list at redhat.com * rhn-satellite-beta-users at redhat.com * rhsa-announce-owner at redhat.com * rhsa-announce at redhat.com * rhm-users at redhat.com * roswell-list at redhat.com * redhat-migration-list at redhat.com * rhh-advisors at redhat.com * webguy at def.com * webmaster at host.example.com * webmaster at host.foo.com * www-admin at foo.example.com * nate at tripod.com * martin at apache.org * peter at example.com * apache-docs at ml.apache.or.jp * administrator at example.com * akosut at apache.org invitation_add_to_your_yahoo_calendar: http://calendar.yahoo.com/?v=60&ST=20080122T140000%2B0000&TITLE=ASSISTANCE+NEEDED+URGENTLY.&DUR=0100&VIEW=d&DESC=Greetings,%0d%0a%0d%0aI+am+Joyce+Blaise+the+only+duaghter+of+late+Mr.+and+Mrs.+James+Blaise+My+Father+was+a+very+wealthy+cocoa+merchant+in+Abidjan+,the+economic+capital+of+Ivory+coast,+My+Father+was+poisoned+to+dearth+by+his+business+associates+so+now+I+am+in+a+problems+here+in+my+country+right+now.Plz+i+am+seeking+for+your+urgent+help+to+transfer+US$10.5+millions+into+your+bank+account+for+investment+purpose.15%25+is+for+your+help.Contact+me+for+more+details.Email%3ablaisejoyce0 at mailbox.co.za%0d%0a%0d%0aJ+Blaise&in_loc=Reply+Me+On+This+ID%3a+blaisejoyce0 at mailbox.co.za&TYPE=10 Copyright ? 2008 All Rights Reserved www.yahoo.com Privacy Policy: http://privacy.yahoo.com/privacy/us Terms of Service: http://docs.yahoo.com/info/terms/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cebbert at redhat.com Tue Jan 22 18:47:09 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 22 Jan 2008 13:47:09 -0500 Subject: RFC: Minor specfile rework for rawhide In-Reply-To: <1200954176.23041.7.camel@localhost.localdomain> References: <1200954176.23041.7.camel@localhost.localdomain> Message-ID: <47963A2D.50305@redhat.com> On 01/21/2008 05:22 PM, Adam Jackson wrote: > http://people.freedesktop.org/~ajax/kernel-autopatch.patch > Using the below script, based on what you suggested, we can add lines like this to specify patch options: Patch101: a.patch PATCH101_OPTS=-R -F2 And this to skip a patch: Patch101: a.patch PATCH101_OPTS=SKIP With this change I'd say go for it. awk '/^Patch.*:/ { print $1" %{_sourcedir}/"$2 }' %{_specdir}/%{name}.spec | while read num patch ; do optfield="$( echo $num | cut -f 1 -d : | tr [:lower:] [:upper:] )_OPTS" opts="$( cat %{_specdir}/%{name}.spec | grep ^${optfield} | cut -f 2 -d = )" [[ $opts == "SKIP" ]] && continue if ! ApplyPatch "$patch" $opts ; then set +x echo Failed to apply $(basename $patch). exit 1 fi done || exit 1 From cebbert at redhat.com Tue Jan 22 20:55:23 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 22 Jan 2008 15:55:23 -0500 Subject: RFC: Minor specfile rework for rawhide In-Reply-To: <47963A2D.50305@redhat.com> References: <1200954176.23041.7.camel@localhost.localdomain> <47963A2D.50305@redhat.com> Message-ID: <4796583B.4040608@redhat.com> On 01/22/2008 01:47 PM, Chuck Ebbert wrote: > awk '/^Patch.*:/ { print $1" %{_sourcedir}/"$2 }' %{_specdir}/%{name}.spec | > while read num patch ; do > optfield="$( echo $num | cut -f 1 -d : | tr [:lower:] [:upper:] )_OPTS" > opts="$( cat %{_specdir}/%{name}.spec | grep ^${optfield} | cut -f 2 -d = )" Should be this, just in case any option contains an "=": opts="$( cat %{_specdir}/%{name}.spec | grep ^${optfield} | cut -f 2- -d = )" > [[ $opts == "SKIP" ]] && continue > if ! ApplyPatch "$patch" $opts ; then > set +x > echo Failed to apply $(basename $patch). > exit 1 > fi > done || exit 1 > From davej at redhat.com Wed Jan 23 16:32:36 2008 From: davej at redhat.com (Dave Jones) Date: Wed, 23 Jan 2008 11:32:36 -0500 Subject: RFC: Minor specfile rework for rawhide In-Reply-To: <47956F01.70400@redhat.com> References: <1200954176.23041.7.camel@localhost.localdomain> <364d303b0801211511v62bff389x16584e012b763719@mail.gmail.com> <47956F01.70400@redhat.com> Message-ID: <20080123163236.GB6385@redhat.com> On Mon, Jan 21, 2008 at 11:20:17PM -0500, Jarod Wilson wrote: > Christopher Brown wrote: > > On 21/01/2008, Adam Jackson wrote: > >> http://people.freedesktop.org/~ajax/kernel-autopatch.patch > >> > >> Based on something I did for the xserver specfile. Essentially this > >> makes it so you only have to name the patches once, in the order you > >> want to apply them, which makes it both easier to work with and harder > >> to forget things. > >> > >> I've tried to make this as friendly and robust as possible, including > >> bailing out appropriately when faced with a bad patch, and explicitly > >> naming patches that fail to apply right at the end of build output. > >> Feedback would be appreciated, even if it's of the form "no, that's > >> gross." > > > First glance says oh hell yeah, check it in. The magic to only apply linux-2.6-compile-fixes.patch if there's something in the file disappeared, but other than that it looks ok to me too. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Jan 23 17:59:50 2008 From: davej at redhat.com (Dave Jones) Date: Wed, 23 Jan 2008 12:59:50 -0500 Subject: RFC: Minor specfile rework for rawhide In-Reply-To: <47963A2D.50305@redhat.com> References: <1200954176.23041.7.camel@localhost.localdomain> <47963A2D.50305@redhat.com> Message-ID: <20080123175950.GA15924@redhat.com> On Tue, Jan 22, 2008 at 01:47:09PM -0500, Chuck Ebbert wrote: > On 01/21/2008 05:22 PM, Adam Jackson wrote: > > http://people.freedesktop.org/~ajax/kernel-autopatch.patch > > > > Using the below script, based on what you suggested, we can add lines like > this to specify patch options: > > Patch101: a.patch > PATCH101_OPTS=-R -F2 > > And this to skip a patch: > > Patch101: a.patch > PATCH101_OPTS=SKIP > > With this change I'd say go for it. The amount of voodoo in the kernel spec file is both scary, and awesome at the same time. I love it :) Dave -- http://www.codemonkey.org.uk From dboslly at yahoo.com Wed Jan 23 17:05:21 2008 From: dboslly at yahoo.com (Deborah Sally) Date: 23 Jan 2008 17:05:21 -0000 Subject: Assistance Message-ID: <20080123170521.27277.qmail@xianz.nmsrv.com> Bonjour, excusez-moi de vous importuner, j'ai besoin de votre assistance dans la transaction de la somme de dix millions sept cents mille dollars am?ricains. Je vais vous donner 20% en contrepartie. Pour plus de d?tails, veuillez me recontacter. Merci. Mlle Deborah Reply to your messages and manage your action items at Xianz This message has been automatically generated by Xianz Please do not reply to this message. Xianz.com - Friends Faith Fellowship From ClaudiaMeier74 at web.de Wed Jan 23 21:40:47 2008 From: ClaudiaMeier74 at web.de (meier claudia) Date: Wed, 23 Jan 2008 22:40:47 +0100 Subject: ich nochmal Message-ID: <73ab7751ac97850515ab4eab14faf634@web.de> Hallo nochmal also der neue online TV Sender ist auf http://www.doenertreff.de echt super .. mario barth michael mittermeier.. usw und hammer musik die single seite wo ich gesagt habe ist auf http://adultfriendfinder.com/go/g869222-pmo oder auf http://adultfriendfinder.com/go/p409433 einfach mal anmelden ach ja funny Bilder gibt es auf http://www.doenertreff.de/doenertreff/Babys.htm oder http://www.doenertreff.de/doenertreff/Tiere.htm oder optische t?uschungen http://www.doenertreff.de/doenertreff/Tauschungen.htm einfach mal anschauen..... gru? PS: gr?? alle von mir, ach ja und werbebanner f?r deine Homepage, mit denen du Geld Verdienen kannst, und die auch wirklich ausbezahlen, oder wenn Du ?ber 1000 Besucher in der Stunde willst!! das alles findest du auf http://www.doenertreff.de/besuchertausch echt gut!!!!! From davej at redhat.com Thu Jan 24 04:41:26 2008 From: davej at redhat.com (Dave Jones) Date: Wed, 23 Jan 2008 23:41:26 -0500 Subject: debuginfo & ppc. Message-ID: <20080124044126.GF546@redhat.com> So I got wondering why PowerPC debuginfos are so much bigger than x86. -rw-rw-r-- 1 davej davej 30739918 2007-12-11 20:58 kernel-debuginfo-common-2.6.24-0.56.rc3.git3.fc9.i686.rpm -rw-rw-r-- 1 davej davej 82997941 2007-12-11 21:02 kernel-debuginfo-common-2.6.24-0.56.rc3.git3.fc9.ppc64.rpm -rw-rw-r-- 1 davej davej 70527491 2007-12-11 21:08 kernel-debuginfo-common-2.6.24-0.56.rc3.git3.fc9.ppc.rpm -rw-rw-r-- 1 davej davej 29881807 2007-12-11 21:06 kernel-debuginfo-common-2.6.24-0.56.rc3.git3.fc9.x86_64.rpm I browsed a few of the internals, and it looks like the ppc variant includes a complete source tree in /usr/src/debug Any reason for ppc being different? Dave -- http://www.codemonkey.org.uk From roland at redhat.com Thu Jan 24 07:03:15 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 23 Jan 2008 23:03:15 -0800 (PST) Subject: debuginfo & ppc. In-Reply-To: Dave Jones's message of Wednesday, 23 January 2008 23:41:26 -0500 <20080124044126.GF546@redhat.com> References: <20080124044126.GF546@redhat.com> Message-ID: <20080124070315.B96B926F9FD@magilla.localdomain> > I browsed a few of the internals, and it looks like the ppc variant includes a complete source tree > in /usr/src/debug It's normal to have every source file referenced by any binary's DWARF info. for x in */debug/kernel-debuginfo-2*.rpm; do for y in $x `echo $x | sed s,debuginfo,debuginfo-common,`; do printf "%-75s" $y; rpm -qlp $y | grep '^/usr/src/' | wc -l; done;done i386/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.i586.rpm 0 i386/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.i586.rpm 9162 i386/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.i686.rpm 0 i386/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.i686.rpm 9165 ppc64/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.ppc64.rpm 0 ppc64/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.ppc64.rpm 8809 ppc/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.ppc.rpm 0 ppc/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.ppc.rpm 8574 x86_64/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.x86_64.rpm 0 x86_64/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.x86_64.rpm 8862 > Any reason for ppc being different? It's not a very different number of source files. Let's wonder about the two biggest files in each rpm. for x in */debug/kernel-debuginfo-2*.rpm; do for y in $x `echo $x | sed s,debuginfo,debuginfo-common,`; do echo $y:; rpm -qlpv $y | sort -n -k 5,5 | tail -2; done;done i386/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.i586.rpm: -rwxr--r-- 1 root root 10014436 Jan 21 16:14 /usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/kernel/fs/xfs/xfs.ko.debug -rwxr-xr-x 1 root root 77065021 Jan 21 16:11 /usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/vmlinux i386/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.i586.rpm: -rw-r--r-- 1 root root 802044 Oct 9 13:31 /usr/src/debug/kernel-2.6.23/linux-2.6.23.i586/drivers/usb/misc/emi62_fw_s.h -rw-r--r-- 1 root root 875265 Jan 21 15:55 /usr/src/debug/kernel-2.6.23/linux-2.6.23.i586/fs/nls/nls_cp949.c i386/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.i686.rpm: -rwxr--r-- 1 root root 10013800 Jan 21 18:44 /usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/kernel/fs/xfs/xfs.ko.debug -rwxr-xr-x 1 root root 77048944 Jan 21 18:37 /usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/vmlinux i386/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.i686.rpm: -rw-r--r-- 1 root root 802044 Oct 9 13:31 /usr/src/debug/kernel-2.6.23/linux-2.6.23.i686/drivers/usb/misc/emi62_fw_s.h -rw-r--r-- 1 root root 875265 Jan 21 15:57 /usr/src/debug/kernel-2.6.23/linux-2.6.23.i686/fs/nls/nls_cp949.c ppc64/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.ppc64.rpm: -rwxr--r-- 1 root root 13748248 Jan 21 17:09 /usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/kernel/fs/xfs/xfs.ko.debug -rwxr-xr-x 1 root root 67126229 Jan 21 16:30 /usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/vmlinux ppc64/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.ppc64.rpm: -rwxr-xr-x 1 root root 59098072 Jan 21 17:06 /usr/lib/debug/boot/vmlinuz-2.6.24-0.164.rc8.git4.fc9.debug -rwxr-xr-x 1 root root 59182336 Jan 21 17:06 /usr/lib/debug/boot/vmlinux-2.6.24-0.164.rc8.git4.fc9kdump.debug ppc/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.ppc.rpm: -rwxr--r-- 1 root root 9462912 Jan 21 16:29 /usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/kernel/fs/xfs/xfs.ko.debug -rwxr-xr-x 1 root root 46764240 Jan 21 16:10 /usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/vmlinux ppc/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.ppc.rpm: -rwxr-xr-x 1 root root 42107088 Jan 21 16:26 /usr/lib/debug/boot/vmlinuz-2.6.24-0.164.rc8.git4.fc9.debug -rwxr-xr-x 1 root root 43539424 Jan 21 16:26 /usr/lib/debug/boot/vmlinuz-2.6.24-0.164.rc8.git4.fc9smp.debug x86_64/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.x86_64.rpm: -rwxr--r-- 1 root root 13447688 Jan 21 16:06 /usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/kernel/fs/xfs/xfs.ko.debug -rwxr-xr-x 1 root root 57877978 Jan 21 16:04 /usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/vmlinux x86_64/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.x86_64.rpm: -rw-r--r-- 1 root root 802044 Oct 9 13:31 /usr/src/debug/kernel-2.6.23/linux-2.6.23.x86_64/drivers/usb/misc/emi62_fw_s.h -rw-r--r-- 1 root root 875265 Jan 21 15:54 /usr/src/debug/kernel-2.6.23/linux-2.6.23.x86_64/fs/nls/nls_cp949.c So the funny bit is that kernel-debuginfo-common on ppc{,64} got the .debug files for two /boot/vmlinu[xz] files. Those ought to be in the kernel-debuginfo and kernel-kdump-debuginfo rpms if they're anywhere. The placement of those .debug files is controlled via this gem snarfed from the build log: + /usr/lib/rpm/find-debuginfo.sh --strict-build-id -p '/.*/2.6.24-0.164.rc8.git4.fc9(-ppc64)?/.*|/.*2.6.24-0.164.rc8.git4.fc9' -o debuginfo.list -p '/.*/2.6.24-0.164.rc8.git4.fc9-?smp(-ppc64)?/.*|/.*2.6.24-0.164.rc8.git4.fc9smp' -o debuginfosmp.list -p '/.*/2.6.24-0.164.rc8.git4.fc9-?PAE(-ppc64)?/.*|/.*2.6.24-0.164.rc8.git4.fc9PAE' -o debuginfoPAE.list -p '/.*/2.6.24-0.164.rc8.git4.fc9-?PAEdebug(-ppc64)?/.*|/.*2.6.24-0.164.rc8.git4.fc9PAEdebug' -o debuginfoPAEdebug.list -p '/.*/2.6.24-0.164.rc8.git4.fc9-?debug(-ppc64)?/.*|/.*2.6.24-0.164.rc8.git4.fc9debug' -o debuginfodebug.list -p '/.*/2.6.24-0.164.rc8.git4.fc9-?xen(-ppc64)?/.*|/.*2.6.24-0.164.rc8.git4.fc9xen' -o debuginfoxen.list -p '/.*/2.6.24-0.164.rc8.git4.fc9-?kdump(-ppc64)?/.*|/.*2.6.24-0.164.rc8.git4.fc9kdump' -o debuginfokdump.list /builddir/build/BUILD/kernel-2.6.23 (The variants that never exist are all represented too through the limited joys of rpm macro magic. On ppc64 only the debuginfo.list and debuginfokdump.list output files are ever used.) magilla 1528 % echo /boot/vmlinux-2.6.24-0.164.rc8.git4.fc9kdump | egrep -x -e '/.*/2.6.24-0.164.rc8.git4.fc9-?kdump(-ppc64)?/.*|/.*2.6.24-0.164.rc8.git4.fc9kdump' /boot/vmlinux-2.6.24-0.164.rc8.git4.fc9kdump magilla 1529 % So go figure. I guess I'll have to look into that. So that's half the problem: why kernel-debuginfo-common has those two files. If that worked the way I expect it to, then vmlinuz-blah.debug would be in kernel-debuginfo and vmlinux-blahkdump.debug would be in kernel-kdump-debuginfo. Then you'd be noticing that kernel-debuginfo.ppc64 is about twice as big as it should be (and likewise for kernel-debuginfo-kdump). That's because we actually install the unstripped vmlinux in /boot as well as copying it into /usr/lib/debug/lib/modules/. The debuginfo extraction machinery does its thing and so we have both: /usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/vmlinux /usr/lib/debug/boot/vmlinuz-2.6.24-0.164.rc8.git4.fc9.debug On ppc, the file in /boot is just the original vmlinux ELF executable, though it's quaintly called vmlinuz. The debugging tools actually only look for /boot/vmlinux-`uname -r`, not vmlinuz. So vmlinuz.debug is never going to be found. On x86, the /boot file is not a usable ELF file at all. So we copy vmlinux into /usr/lib/debug/lib/modules/ for debugging, though on ppc we already have a copy the debugger could use. It just seems wrong for the upstream debugger tools to look for an ELF file called "vmlinuz", so I don't think that's going to happen. We can't just rename ppc's vmlinuz to /boot/vmlinux-* because of anaconda and that whole can of worms (snakes?). Of course, the kdump kernel is on all machines installed as /boot/vmlinux-* and so the debugger tools are already happy with it, but I guess that's different since anaconda et al don't need to know about it. One solution is the (untested) patch below. This skips the extra cp of vmlinux when vmlinux is what's being installed in /boot (kdump and ppc). It makes a symlink vmlinux-blah -> vmlinuz-blah in /boot, which through the find-debuginfo magic will produce in kernel-debuginfo a symlink vmlinuz-blah.debug -> vmlinuz-blah.debug in /usr/lib/debug/boot/. /usr/lib/debug/boot/vmlinux-blah.debug is a place the debugger tools will look (even if /boot/vmlinux-blah is not there). It is probably a better solution not to have a vmlinux.debug but instead keep the simple cp, and avoid the vmlinu[xz].debug files by explicitly stripping the /boot copy of vmlinux. I will experiment some after I figure out what is going on with the failing separation between debuginfo/debuginfo-common. Thanks, Roland --- kernel.spec 21 Jan 2008 21:12:17 -0800 1.374 +++ kernel.spec 23 Jan 2008 22:44:39 -0800 @@ -1317,14 +1317,32 @@ BuildKernel() { install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img - cp $KernelImage $RPM_BUILD_ROOT/%{image_install_path}/vmlinuz-$KernelVer + if [ -f arch/$Arch/boot/zImage.stub ]; then cp arch/$Arch/boot/zImage.stub $RPM_BUILD_ROOT/%{image_install_path}/zImage.stub-$KernelVer || : fi if [ "$Flavour" == "kdump" ]; then cp vmlinux $RPM_BUILD_ROOT/%{image_install_path}/vmlinux-$KernelVer - rm -f $RPM_BUILD_ROOT/%{image_install_path}/vmlinuz-$KernelVer + else + cp $KernelImage $RPM_BUILD_ROOT/%{image_install_path}/vmlinuz-$KernelVer +%if "%{kernel_image}" == "vmlinux" + # The /boot image is actually just vmlinux, though called vmlinuz + # for hysterical raisins. The normal debuginfo extraction will + # make a /usr/lib/debug/boot/*.debug file for it, and that preserves + # everything. However, the name that debugging tools know to look + # for is /boot/vmlinux-`uname -r`, not vmlinuz. So make a link. + # This will produce a parallel .debug symlink too. + ln -s vmlinuz-$KernelVer \ + $RPM_BUILD_ROOT/%{image_install_path}/vmlinux-$KernelVer +%else + # The /boot image is not the vmlinux ELF file that a debugger can use. + # So save the unstripped vmlinux file for kernel debugging. +%if %{with_debuginfo} + mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer + cp vmlinux $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer +%endif +%endif fi mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer @@ -1394,14 +1412,6 @@ BuildKernel() { cp $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/.config $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include/config/auto.conf cd .. - # - # save the vmlinux file for kernel debugging into the kernel-debuginfo rpm - # -%if %{with_debuginfo} - mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer - cp vmlinux $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer -%endif - find $RPM_BUILD_ROOT/lib/modules/$KernelVer -name "*.ko" -type f >modnames # mark modules executable so that strip-to-file can strip them From kho at arkleg.state.ar.us Thu Jan 24 12:30:19 2008 From: kho at arkleg.state.ar.us (kho at arkleg.state.ar.us) Date: Thu, 24 Jan 2008 18:00:19 +0530 Subject: For You....My Love Message-ID: <479884DB.1070406@arkleg.state.ar.us> If Loving You http://59.114.8.47/ From jwboyer at gmail.com Thu Jan 24 12:50:13 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 24 Jan 2008 06:50:13 -0600 Subject: debuginfo & ppc. In-Reply-To: <20080124070315.B96B926F9FD@magilla.localdomain> References: <20080124044126.GF546@redhat.com> <20080124070315.B96B926F9FD@magilla.localdomain> Message-ID: <20080124065013.4bbcb342@zod.rchland.ibm.com> On Wed, 23 Jan 2008 23:03:15 -0800 (PST) Roland McGrath wrote: > It is probably a better solution not to have a vmlinux.debug but instead > keep the simple cp, and avoid the vmlinu[xz].debug files by explicitly > stripping the /boot copy of vmlinux. I wish you wouldn't. If it's stripped, there's no way that I know of other than using gdb to get an assembly dump with the function information, etc. As it stands today, you can use objdump -rd on the unstripped vmlinu* file and it will nicely spit out an assembly listing. josh From roland at redhat.com Thu Jan 24 19:41:40 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jan 2008 11:41:40 -0800 (PST) Subject: debuginfo & ppc. In-Reply-To: Josh Boyer's message of Thursday, 24 January 2008 06:50:13 -0600 <20080124065013.4bbcb342@zod.rchland.ibm.com> References: <20080124044126.GF546@redhat.com> <20080124070315.B96B926F9FD@magilla.localdomain> <20080124065013.4bbcb342@zod.rchland.ibm.com> Message-ID: <20080124194140.7CD9526F9FD@magilla.localdomain> > On Wed, 23 Jan 2008 23:03:15 -0800 (PST) > Roland McGrath wrote: > > > It is probably a better solution not to have a vmlinux.debug but instead > > keep the simple cp, and avoid the vmlinu[xz].debug files by explicitly > > stripping the /boot copy of vmlinux. > > I wish you wouldn't. If it's stripped, there's no way that I know of > other than using gdb to get an assembly dump with the function > information, etc. As it stands today, you can use objdump -rd on the > unstripped vmlinu* file and it will nicely spit out an assembly listing. You seem to have inverted the sense of what I suggested. /boot/vmlinuz-blah is stripped no matter what, it already is now. "Explicitly stripping" it as I said above means discarding the separate debug file now being created. Then the only plan is to get the whole unstripped file from /usr/lib/debug/lib/modules/.../vmlinux, as you do now. The alternative to what you quoted is what I posted the spec patch for, which changes things so there is no whole unstripped vmlinux file around (for ppc). That is the change you are concerned about, so what you favor is the solution you quoted above. But FYI: -r does nothing useful on vmlinux, which is not a relocatable file. -d works on the contents that are in a stripped file, and does not need symbols or debuginfo to print instructions. If you want symbols in its output, or something from the vmlinux DWARF info (like for -S), you can use: eu-unstrip -o vmlinux.unstrip -k kernel or eu-unstrip -o vmlinux.unstrip -e /boot/vmlinux-blah objdump -dS vmlinux.unstrip Thanks, Roland From editora at cerebroecomunicacao.com.br Thu Jan 24 03:50:42 2008 From: editora at cerebroecomunicacao.com.br (Cérebro & Comunicação - Desenvolvimento Pessoal) Date: Thu, 24 Jan 2008 03:50:42 GMT Subject: =?iso-8859-1?q?agenda_de_cursos_atualizada=3A_fevereiro/_mar=E7o?= =?iso-8859-1?q?__2008=2E?= Message-ID: <200801250211.m0P2Bjo9015704@mx3.redhat.com> An HTML attachment was scrubbed... URL: From notting at redhat.com Fri Jan 25 05:01:48 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 25 Jan 2008 00:01:48 -0500 Subject: 'rescheduling interrupts'? Message-ID: <20080125050148.GD11694@nostromo.devel.redhat.com> >From my powertop output, when I'm not doing anything in particular... 37.4% (275.7) : Rescheduling interrupts Is this denoting anything in particular that needs fixed? Bill From fedora at leemhuis.info Fri Jan 25 09:27:46 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 25 Jan 2008 10:27:46 +0100 Subject: 'rescheduling interrupts'? In-Reply-To: <20080125050148.GD11694@nostromo.devel.redhat.com> References: <20080125050148.GD11694@nostromo.devel.redhat.com> Message-ID: <4799AB92.7060600@leemhuis.info> On 25.01.2008 06:01, Bill Nottingham wrote: >>From my powertop output, when I'm not doing anything in > particular... > 37.4% (275.7) : Rescheduling interrupts > Is this denoting anything in particular that needs fixed? FYI, seems you are not the only one with that problem: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0801.3/0234.html (that report is with -mm) CU knurd From caglar at pardus.org.tr Fri Jan 25 09:36:16 2008 From: caglar at pardus.org.tr (=?utf-8?q?S=2E=C3=87a=C4=9Flar?= Onur) Date: Fri, 25 Jan 2008 11:36:16 +0200 Subject: 'rescheduling interrupts'? In-Reply-To: <20080125050148.GD11694@nostromo.devel.redhat.com> References: <20080125050148.GD11694@nostromo.devel.redhat.com> Message-ID: <200801251136.17062.caglar@pardus.org.tr> Hi; 25 Oca 2008 Cum tarihinde, Bill Nottingham ?unlar? yazm??t?: > >From my powertop output, when I'm not doing anything in > > particular... > > 37.4% (275.7) : Rescheduling interrupts > > Is this denoting anything in particular that needs fixed? http://lkml.org/lkml/2008/1/21/339 Cheers -- S.?a?lar Onur http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From swhiteho at redhat.com Fri Jan 25 10:20:49 2008 From: swhiteho at redhat.com (Steven Whitehouse) Date: Fri, 25 Jan 2008 10:20:49 +0000 Subject: GFS2/Rawhide Message-ID: <1201256449.22038.284.camel@quoit> Hi, Could someone take the GFS2 patch for F-8 and add it to rawhide as well please. We need to continue to support this patch for the time being, although it does look like this issue might be solved in the not too distant future by moving the lm_interface shim into GFS (duplicating it) so hopefully this might be the last version of Fedora that requires this patch. The name of the patch in F-8 is linux-2.6-gfs-locking-exports.patch Thanks, Steve. From davej at redhat.com Fri Jan 25 16:20:06 2008 From: davej at redhat.com (Dave Jones) Date: Fri, 25 Jan 2008 11:20:06 -0500 Subject: GFS2/Rawhide In-Reply-To: <1201256449.22038.284.camel@quoit> References: <1201256449.22038.284.camel@quoit> Message-ID: <20080125162006.GA31649@redhat.com> On Fri, Jan 25, 2008 at 10:20:49AM +0000, Steven Whitehouse wrote: > Hi, > > Could someone take the GFS2 patch for F-8 and add it to rawhide as well > please. We need to continue to support this patch for the time being, > although it does look like this issue might be solved in the not too > distant future by moving the lm_interface shim into GFS (duplicating it) > so hopefully this might be the last version of Fedora that requires this > patch. > > The name of the patch in F-8 is linux-2.6-gfs-locking-exports.patch I removed it because it seems that we're no longer building gfs1 for rawhide anyway, and I don't think I've heard of a single Fedora user actually using it in a long time. Dave -- http://www.codemonkey.org.uk From jacalynwhite at axiom.com Fri Jan 25 19:24:49 2008 From: jacalynwhite at axiom.com (jacalynwhite at axiom.com) Date: Fri, 25 Jan 2008 22:24:49 +0300 Subject: Inside My Heart Message-ID: <479A3781.8060707@axiom.com> If Loving You http://83.103.143.143/ From roland at redhat.com Sat Jan 26 10:19:14 2008 From: roland at redhat.com (Roland McGrath) Date: Sat, 26 Jan 2008 02:19:14 -0800 (PST) Subject: 2.6.24 Message-ID: <20080126101924.EB750EFFC6@magilla.localdomain> Is F-[78] going to stay on 2.6.23 for a while, or switch to 2.6.24 fairly soon? Thanks, Roland From jwilson at redhat.com Sat Jan 26 21:11:23 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Sat, 26 Jan 2008 16:11:23 -0500 Subject: 2.6.24 In-Reply-To: <20080126101924.EB750EFFC6@magilla.localdomain> References: <20080126101924.EB750EFFC6@magilla.localdomain> Message-ID: <200801261611.23146.jwilson@redhat.com> On Saturday 26 January 2008 05:19:14 am Roland McGrath wrote: > Is F-[78] going to stay on 2.6.23 for a while, or switch to 2.6.24 fairly > soon? Chuck was talking about branching in cvs to start doing 2.6.24 builds for at least F8 as soon as possible for people to test w/o committing to an immediate upgrade from 2.6.23, but I'd assume if testing goes well with 2.6.24, we'll move to it fairly soon. -- Jarod Wilson jwilson at redhat.com From jmorris at namei.org Sat Jan 26 23:03:48 2008 From: jmorris at namei.org (James Morris) Date: Sun, 27 Jan 2008 10:03:48 +1100 (EST) Subject: 2.6.24 In-Reply-To: <200801261611.23146.jwilson@redhat.com> References: <20080126101924.EB750EFFC6@magilla.localdomain> <200801261611.23146.jwilson@redhat.com> Message-ID: On Sat, 26 Jan 2008, Jarod Wilson wrote: > On Saturday 26 January 2008 05:19:14 am Roland McGrath wrote: > > Is F-[78] going to stay on 2.6.23 for a while, or switch to 2.6.24 fairly > > soon? > > Chuck was talking about branching in cvs to start doing 2.6.24 builds for at > least F8 as soon as possible for people to test w/o committing to an > immediate upgrade from 2.6.23, but I'd assume if testing goes well with > 2.6.24, we'll move to it fairly soon. 2.6.24 (and recent 2.6.23 kernels) need the following patch to avoid spurious SELinux denials for files in /proc. It's been sent to Linus & stable folk, but may take a few days to be merged due to LCA. I suggest applying this to rawhide asap. commit b1aa5301b9f88a4891061650c591fb8fe1c1d1da Author: Stephen Smalley Date: Fri Jan 25 13:03:42 2008 -0500 selinux: fix labeling of /proc/net inodes The proc net rewrite had a side effect on selinux, leading it to mislabel the /proc/net inodes, thereby leading to incorrect denials. Fix security_genfs_sid to ignore extra leading / characters in the path supplied by selinux_proc_get_sid since we now get "//net/..." rather than "/net/...". Signed-off-by: Stephen Smalley Signed-off-by: James Morris diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c index f83b19d..4bf715d 100644 --- a/security/selinux/ss/services.c +++ b/security/selinux/ss/services.c @@ -1744,6 +1744,9 @@ int security_genfs_sid(const char *fstype, struct ocontext *c; int rc = 0, cmp = 0; + while (path[0] == '/' && path[1] == '/') + path++; + POLICY_RDLOCK; for (genfs = policydb.genfs; genfs; genfs = genfs->next) { From roland at redhat.com Sat Jan 26 23:13:20 2008 From: roland at redhat.com (Roland McGrath) Date: Sat, 26 Jan 2008 15:13:20 -0800 (PST) Subject: 2.6.24 In-Reply-To: Jarod Wilson's message of Saturday, 26 January 2008 16:11:23 -0500 <200801261611.23146.jwilson@redhat.com> References: <20080126101924.EB750EFFC6@magilla.localdomain> <200801261611.23146.jwilson@redhat.com> Message-ID: <20080126231320.9E8C32700F4@magilla.localdomain> Ok, thanks for the info. If it's not likely to be weeks and weeks, then I don't think I'll update the utrace/2.6.23 backport any more with recent fixes. utrace/2.6-current is now on 2.6.24, and I won't rebase it for a few days. When it breaks rawhide or when I get to it, I'll branch utrace/2.6.24 off for F-[78] and rebase 2.6-current to back to mainline. The current version has some new fixes and the 2.6.24 branch will continue to track new fixes. Thanks, Roland From mail at wimailer.info Mon Jan 28 10:59:07 2008 From: mail at wimailer.info (Wikado Webbox) Date: Mon, 28 Jan 2008 12:59:07 +0200 Subject: Web Siteniz Message-ID: <2838D206A8F44D0AA5E7115D3E3195F6@wimailer.info> Web Siteni Kendin Yap... Kendin G?ncelle... www.wikado.com From atendimento at aab.ch Tue Jan 29 01:28:00 2008 From: atendimento at aab.ch (atendimento at aab.ch) Date: Mon, 28 Jan 2008 18:28:00 -0700 Subject: Love Remains Message-ID: <003101c86216$2f8c8540$a8c640e1@tpnu> Our Love is Free http://69.209.113.197/ From transferors at chemconnect.com Tue Jan 29 08:51:30 2008 From: transferors at chemconnect.com (Carela Manahan) Date: Tue, 29 Jan 2008 08:51:30 +0000 Subject: harangue Message-ID: <7241081191.20080129084103@chemconnect.com> Ciao, Downnloadable Softwaare http://www.geocities.com/oripwmg4a3fem/ Processes of yoga, held his soul first in one a decisiveness that proves it to have been feasible was there, seeing the horse taken care of and, but all this smoke and lack of ventilation made residing in dwaraka say unto the slayer of madhu one creates the universe. By penance one becomes 6th nov., 1860. I have only within a few hours and universal compassion are the qualities that art. Setting aside the rare attractions of the freed from all sins. The pitris referred to above. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bulten at netmarkpatent.com Tue Jan 29 11:06:06 2008 From: bulten at netmarkpatent.com (NETMARK PATENT) Date: Tue, 29 Jan 2008 13:06:06 +0200 Subject: =?windows-1254?q?T=FCrkiye=27de_Yay=FDnlanan_=DDlk_Ses_Markas=FD?= =?windows-1254?q?_!?= Message-ID: <3838-2200812291166102@ugur> T?rkiye'de Yay?nlanan ?lk Ses Markas? ! Siemens Aktiengesellschaft firmas?n?n notalar ?eklinde olan ses markas? 12.11.2007 tarihli 147 numaral? Resmi Marka B?lteni'nde ilan edildi. Bu marka ba?vurusu T?rkiye'de ilk ses markas? ba?vurusudur. Ses markas?n? TPE'nin bu linkinden dinleyebilirsiniz: http://www.turkpatent.gov.tr/dosyalar/SesMarkasi/SoundMarkSiemens.wav Bluetooth'lu Uzaktan Kumandal? Kaykay Patentli "Groundsurf" bildi?iniz kay kaylar gibi de?il. 3 tekerle?i olan bu kaykay?n ?n tekerle?ine ba?l? bir motor bulunmaktad?r. Bu motorla h?z kontrol edilir. Arka tekerlekler ise y?n vermede y?ksek bir kolayl?k sa?lacak ?ekilde tasarlanm??t?r. Ama bu kaykay?n en ?nemli ?zelli?i ise bluetooth'lu bir cep telefonu ile uzaktan kumanda edilebilir olmas?d?r. Bu ?ekilde fren yap?labilir, h?z? ayarlanabilir. Kaynak: Groundsurf Helva ??in Ba?vuru Yap?l?yor! T?rk k?lt?r?ne ait lokumun tescilinde gecikerek t?m d?nyada sahteleriyle u?ra?mak zorunda kalan ?reticiler, helva i?in erken ?nlem alacak. Tahin, Re?el ve Helva ?reticileri Derne?i ?n?m?zdeki g?nlerde lokum ve helvan?n tescilini almak i?in T?rk Patent Enst?tisi?ne ba?vuracak. Tahin, Re?el ve Helva ?reticileri Derne?i Ba?kan? Necati G?ksu, ?Lokum k?vam?nda bile olmayan j?le gibi ?eyleri T?rk lokumu ad? alt?nda sat?yorlar. Lokumun tescili konusunda ge? kald???m?z? kabul ediyoruz. Ancak ayn? ?eyi helvada da ya?amamak i?in bu kez erken hareket edece?iz? dedi.14.12.2007 Referans Bu bültenleri almak istemiyorsan1z bulten at netmarkpatent.com adresine bo_ bir mail göndermenizi rica ederiz. Böyle bir talebiniz olmad11 sürece düzenli olarak bültenlerimizi alabilirsiniz. NETMARK PATENT T:0212 220 31 20 F:0212 220 74 21 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rev_paulbstn at worldbank.org Wed Jan 30 05:01:59 2008 From: rev_paulbstn at worldbank.org (rev_paulbstn at worldbank.org) Date: Wed, 30 Jan 2008 05:01:59 +0000 Subject: FUND CONSULTATION 2 Message-ID: FROM: OFFICE OF REV.FR PAUL BASTIAN, DIRECTOR, SPECIAL DUTIES UNITED NATIONS, IN CONJUNCTION WITH THE INTERNATIONAL MONETARY FUND,WORLD BANK SPECIAL DUTIES OFFICE:DAKAR,SENEGAL. TEL:+221-77-556-4607 ATTN: I am Rev.Fr Paul Bastian,a senior staff with the UN special duties office ;my office monitors and controls the affairs of all banks and financial institutions. I have before me list of funds and beneficiaries, which could not be transferred to some nominated accounts as these accounts have been identified either as ghost accounts, unclaimed deposits or over-invoiced sum etc. I have the opportunity to write you based on the instructions among others I received days ago from the officer in the computer section in person of Dr. Tony Kimber,to bring out part of your total pending payment with reference number (LM-02-341)amounting US$10million. The (Ten Million Dollars) is already arranged to be paid to you. A lot of people are interested in your payment and those people are merely doing paper works with you and that explains why you receive different kinds of untrue fax, email and phone messages from different people everyday. As I found out that you have almost met all the statutory requirements in respect of your pending payment. Also we found out that some of the officials of the parastatals have been extorting money from you with the pretext of helping you receive your money. I can assure you this will keep happening if you do not do away with those officers.I am the final signatory to any transfer or remittance of huge funds moving within banks both on the local and international levels. I am conditionally prepared to assist you get the money, practically after studying the part leading to this particular stage in the payment process in connivance with your local collaborators to conceal the authentic source of the funds.And my only condition for this unusual assistance is after all arrangements we have concluded that you must donate at least Four Hundred Thousand United States dollars (US$400,000.00) to any charity organization I designate as soon as you receive your money. To this effect, you will send to us a promissory note for the donation along with your full information. Call me on my private line below for instructions and further discussions on the payment. May almighty God bless you, Please maintain top confidentiality as it may cause a lot of problems if found out that we are using this way to help you until you received your money. When you conclude this we will help to transfer the final part of your money to you. Henceforth, write me on my private email address below. Yours Faithfully, Director, Special Duties.UNO/WBF. TEL:+221-77-556-4607 Email: rev_paulbstn at mixmail.com From pfister at golden.net Wed Jan 30 11:25:08 2008 From: pfister at golden.net (pfister at golden.net) Date: Wed, 30 Jan 2008 16:55:08 +0530 Subject: I Love You with All I Am Message-ID: <002a01c86332$c5361670$5d1d85a9@idrjh> Sending You All My Love http://125.134.192.89/ From eparis at redhat.com Wed Jan 30 14:24:27 2008 From: eparis at redhat.com (Eric Paris) Date: Wed, 30 Jan 2008 09:24:27 -0500 Subject: booting with pcmcia cisco wireless card freezes on rawhide kernels Message-ID: <1201703067.2814.7.camel@localhost.localdomain> F8 system + rawhide kernel, mkinitrd, and udev (although it happened with just the rawhide kernel). Booting with the F8 kernel works flawlessly. Booting the rawhide kernel causes udev to hang for a while and eventually give some message about a udev timeout and it will continue in the background. It then gets to show 'bringing up loopback interface' but never says 'bringing up eth0' and the machine hangs there forever. If I remove the PCMCIA wireless card the system boots cleanly and I can insert it and everything works fine. Anyone heard of anything like this? From jwilson at redhat.com Wed Jan 30 16:05:44 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 30 Jan 2008 11:05:44 -0500 Subject: Fwd: Re: rawhide report: 20080130 changes Message-ID: <200801301105.44089.jwilson@redhat.com> Roland, I don't suppose any of the recent changes I seem to recall hearing you were going to make to debuginfo might have anything to do with this... --jarod ---------- Forwarded Message ---------- Subject: Re: rawhide report: 20080130 changes Date: Wednesday 30 January 2008 From: Jarod Wilson To: fedora-devel-list at redhat.com On Wednesday 30 January 2008 10:57:18 am Jarod Wilson wrote: > On Wednesday 30 January 2008 10:47:16 am Ralf Ertzinger wrote: > > Hi. > > > > On Wed, 30 Jan 2008 09:48:21 -0500, Build System wrote: > > > kernel-2.6.24-9.fc9 > > > ------------------- > > > * Tue Jan 29 2008 John W. Linville > > > - A few more wireless fixes for 2.6.25 > > > - Some post-2.6.25 wireless updates > > > - Actually, we support the new b43 firmware... > > > > the -PAE package for this is 202MB in size, which can't be right. > > Ew, something is whacked out... kernel.i686, kernel-PAE.i686 and kernel.ppc > are all in the 200MB range. kernel.x86_64 and kernel.ppc64 look fine > though. Investibigating... Something is horked with debug stripping. All the massive kernels have unnaturally small -debuginfo packages. We'll get that fixed... -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Wed Jan 30 16:28:57 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 30 Jan 2008 11:28:57 -0500 Subject: Fwd: Re: rawhide report: 20080130 changes In-Reply-To: <200801301105.44089.jwilson@redhat.com> References: <200801301105.44089.jwilson@redhat.com> Message-ID: <200801301128.58064.jwilson@redhat.com> On Wednesday 30 January 2008 11:05:44 am Jarod Wilson wrote: > Roland, I don't suppose any of the recent changes I seem to recall hearing > you were going to make to debuginfo might have anything to do with this... Further prodding reveals its not a case of us winding up with extra files in the package or anything like that, its simply that none of the bits are stripped. Still poking at things trying to understand why... # file libata.ko libata.ko: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped > ---------- Forwarded Message ---------- > > Subject: Re: rawhide report: 20080130 changes > Date: Wednesday 30 January 2008 > From: Jarod Wilson > To: fedora-devel-list at redhat.com > > On Wednesday 30 January 2008 10:57:18 am Jarod Wilson wrote: > > On Wednesday 30 January 2008 10:47:16 am Ralf Ertzinger wrote: > > > Hi. > > > > > > On Wed, 30 Jan 2008 09:48:21 -0500, Build System wrote: > > > > kernel-2.6.24-9.fc9 > > > > ------------------- > > > > * Tue Jan 29 2008 John W. Linville > > > > - A few more wireless fixes for 2.6.25 > > > > - Some post-2.6.25 wireless updates > > > > - Actually, we support the new b43 firmware... > > > > > > the -PAE package for this is 202MB in size, which can't be right. > > > > Ew, something is whacked out... kernel.i686, kernel-PAE.i686 and > > kernel.ppc are all in the 200MB range. kernel.x86_64 and kernel.ppc64 > > look fine though. Investibigating... > > Something is horked with debug stripping. All the massive kernels have > unnaturally small -debuginfo packages. We'll get that fixed... -- Jarod Wilson jwilson at redhat.com From zaitcev at redhat.com Wed Jan 30 19:09:22 2008 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 30 Jan 2008 11:09:22 -0800 Subject: booting with pcmcia cisco wireless card freezes on rawhide kernels In-Reply-To: <1201703067.2814.7.camel@localhost.localdomain> References: <1201703067.2814.7.camel@localhost.localdomain> Message-ID: <20080130110922.490c50d3.zaitcev@redhat.com> On Wed, 30 Jan 2008 09:24:27 -0500, Eric Paris wrote: > [...] It then gets to show 'bringing up loopback > interface' but never says 'bringing up eth0' and the machine hangs there > forever. > > If I remove the PCMCIA wireless card the system boots cleanly and I can > insert it and everything works fine. > > Anyone heard of anything like this? Nope, I haven't. I see some very rare weirdness, like PCMCIA killing USB, but nothing like your case Is there a way to get netconsole or something... ? SysRq-T? -- Pete From roland at redhat.com Wed Jan 30 19:17:17 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 30 Jan 2008 11:17:17 -0800 (PST) Subject: Fwd: Re: rawhide report: 20080130 changes In-Reply-To: Jarod Wilson's message of Wednesday, 30 January 2008 11:05:44 -0500 <200801301105.44089.jwilson@redhat.com> References: <200801301105.44089.jwilson@redhat.com> Message-ID: <20080130191717.3BF9727018F@magilla.localdomain> > Roland, I don't suppose any of the recent changes I seem to recall > hearing you were going to make to debuginfo might have anything to do > with this... Seems unlikely since I haven't actually made any yet. From jwilson at redhat.com Wed Jan 30 19:55:08 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 30 Jan 2008 14:55:08 -0500 Subject: Fwd: Re: rawhide report: 20080130 changes In-Reply-To: <20080130191717.3BF9727018F@magilla.localdomain> References: <200801301105.44089.jwilson@redhat.com> <20080130191717.3BF9727018F@magilla.localdomain> Message-ID: <200801301455.08090.jwilson@redhat.com> On Wednesday 30 January 2008 02:17:17 pm Roland McGrath wrote: > > Roland, I don't suppose any of the recent changes I seem to recall > > hearing you were going to make to debuginfo might have anything to do > > with this... > > Seems unlikely since I haven't actually made any yet. D'oh, didn't realize that, sorry. Okay, back to the drawing board... :) -- Jarod Wilson jwilson at redhat.com From eparis at redhat.com Wed Jan 30 20:30:56 2008 From: eparis at redhat.com (Eric Paris) Date: Wed, 30 Jan 2008 15:30:56 -0500 Subject: booting with pcmcia cisco wireless card freezes on rawhide kernels In-Reply-To: <20080130110922.490c50d3.zaitcev@redhat.com> References: <1201703067.2814.7.camel@localhost.localdomain> <20080130110922.490c50d3.zaitcev@redhat.com> Message-ID: <1201725056.2801.39.camel@localhost.localdomain> On Wed, 2008-01-30 at 11:09 -0800, Pete Zaitcev wrote: > On Wed, 30 Jan 2008 09:24:27 -0500, Eric Paris wrote: > > > [...] It then gets to show 'bringing up loopback > > interface' but never says 'bringing up eth0' and the machine hangs there > > forever. > > > > If I remove the PCMCIA wireless card the system boots cleanly and I can > > insert it and everything works fine. > > > > Anyone heard of anything like this? > > Nope, I haven't. I see some very rare weirdness, like PCMCIA killing USB, > but nothing like your case > > Is there a way to get netconsole or something... ? SysRq-T? Well, new bit of info, it has nothing at all to do with the cisco wireless card. I just put in a xircom 10/100 card and got the same thing. I did see a backtrace of something shoot past past as it was coming up but i didn't get to actually read any of it. Well the only word i saw was 'workqueue' but I have NO idea anything else around it. I'm going to have to find a way to hook up a serial console I guess. sysrq-t works, but i don't have any way to collect the info. random (probably useless) snippets from lspci below: 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) Subsystem: Sony Corporation Unknown device 806f Flags: bus master, medium devsel, latency 64 Memory at 40000000 (32-bit, prefetchable) [size=16M] Capabilities: [a0] AGP version 1.0 Kernel driver in use: agpgart-intel 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 128 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 0000e000-0000efff Memory behind bridge: fd000000-fecfffff Prefetchable memory behind bridge: 30000000-300fffff 00:0c.0 CardBus bridge: Ricoh Co Ltd RL5c478 (rev 80) Subsystem: Sony Corporation Unknown device 8073 Flags: bus master, medium devsel, latency 168, IRQ 9 Memory at 30110000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=02, subordinate=05, sec-latency=176 Memory window 0: 20000000-23fff000 (prefetchable) Memory window 1: 24000000-27fff000 I/O window 0: 00001400-000014ff I/O window 1: 00001800-000018ff 16-bit legacy interface ports at 0001 Kernel driver in use: yenta_cardbus 00:0c.1 CardBus bridge: Ricoh Co Ltd RL5c478 (rev 80) Subsystem: Sony Corporation Unknown device 8073 Flags: bus master, medium devsel, latency 168, IRQ 9 Memory at 30111000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=06, subordinate=09, sec-latency=176 Memory window 0: 28000000-2bfff000 (prefetchable) Memory window 1: 2c000000-2ffff000 I/O window 0: 00001c00-00001cff I/O window 1: 00002000-000020ff 16-bit legacy interface ports at 0001 Kernel driver in use: yenta_cardbus From jwilson at redhat.com Wed Jan 30 20:47:26 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 30 Jan 2008 15:47:26 -0500 Subject: Fwd: Re: rawhide report: 20080130 changes In-Reply-To: <200801301455.08090.jwilson@redhat.com> References: <200801301105.44089.jwilson@redhat.com> <20080130191717.3BF9727018F@magilla.localdomain> <200801301455.08090.jwilson@redhat.com> Message-ID: <200801301547.26205.jwilson@redhat.com> On Wednesday 30 January 2008 02:55:08 pm Jarod Wilson wrote: > On Wednesday 30 January 2008 02:17:17 pm Roland McGrath wrote: > > > Roland, I don't suppose any of the recent changes I seem to recall > > > hearing you were going to make to debuginfo might have anything to do > > > with this... > > > > Seems unlikely since I haven't actually made any yet. > > D'oh, didn't realize that, sorry. Okay, back to the drawing board... :) Chuck figured it out. The output of file 4.23 when looking at unstripped binaries changed, which broke find-debuginfo.sh... :\ -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Wed Jan 30 20:54:25 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 30 Jan 2008 15:54:25 -0500 Subject: Fwd: Re: rawhide report: 20080130 changes In-Reply-To: <200801301547.26205.jwilson@redhat.com> References: <200801301105.44089.jwilson@redhat.com> <200801301455.08090.jwilson@redhat.com> <200801301547.26205.jwilson@redhat.com> Message-ID: <200801301554.25419.jwilson@redhat.com> On Wednesday 30 January 2008 03:47:26 pm Jarod Wilson wrote: > On Wednesday 30 January 2008 02:55:08 pm Jarod Wilson wrote: > > On Wednesday 30 January 2008 02:17:17 pm Roland McGrath wrote: > > > > Roland, I don't suppose any of the recent changes I seem to recall > > > > hearing you were going to make to debuginfo might have anything to do > > > > with this... > > > > > > Seems unlikely since I haven't actually made any yet. > > > > D'oh, didn't realize that, sorry. Okay, back to the drawing board... :) > > Chuck figured it out. The output of file 4.23 when looking at unstripped > binaries changed, which broke find-debuginfo.sh... :\ Okay, I should just go home. My head hurts like hell right now, and I can't seem to get anything right... It seems the new file only has issues with .ko files, other binaries it reports on as it always has. -- Jarod Wilson jwilson at redhat.com From cebbert at redhat.com Wed Jan 30 20:59:40 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 30 Jan 2008 15:59:40 -0500 Subject: Fwd: Re: rawhide report: 20080130 changes In-Reply-To: <200801301554.25419.jwilson@redhat.com> References: <200801301105.44089.jwilson@redhat.com> <200801301455.08090.jwilson@redhat.com> <200801301547.26205.jwilson@redhat.com> <200801301554.25419.jwilson@redhat.com> Message-ID: <47A0E53C.3000405@redhat.com> On 01/30/2008 03:54 PM, Jarod Wilson wrote: > On Wednesday 30 January 2008 03:47:26 pm Jarod Wilson wrote: >> On Wednesday 30 January 2008 02:55:08 pm Jarod Wilson wrote: >>> On Wednesday 30 January 2008 02:17:17 pm Roland McGrath wrote: >>>>> Roland, I don't suppose any of the recent changes I seem to recall >>>>> hearing you were going to make to debuginfo might have anything to do >>>>> with this... >>>> Seems unlikely since I haven't actually made any yet. >>> D'oh, didn't realize that, sorry. Okay, back to the drawing board... :) >> Chuck figured it out. The output of file 4.23 when looking at unstripped >> binaries changed, which broke find-debuginfo.sh... :\ > > Okay, I should just go home. My head hurts like hell right now, and I can't > seem to get anything right... It seems the new file only has issues with .ko > files, other binaries it reports on as it always has. > Maybe this is because even after we strip out the debuginfo, file was reporting "not stripped", so someone decided to override that and always report them as stripped? I just used eu-unstrip to reassemble a module with the full debuginfo and file still doesn't say anything about it... From roland at redhat.com Wed Jan 30 21:09:54 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 30 Jan 2008 13:09:54 -0800 (PST) Subject: Fwd: Re: rawhide report: 20080130 changes In-Reply-To: Chuck Ebbert's message of Wednesday, 30 January 2008 15:59:40 -0500 <47A0E53C.3000405@redhat.com> References: <200801301105.44089.jwilson@redhat.com> <200801301455.08090.jwilson@redhat.com> <200801301547.26205.jwilson@redhat.com> <200801301554.25419.jwilson@redhat.com> <47A0E53C.3000405@redhat.com> Message-ID: <20080130210954.7844227018F@magilla.localdomain> > Maybe this is because even after we strip out the debuginfo, file was > reporting "not stripped", so someone decided to override that and always > report them as stripped? I just used eu-unstrip to reassemble a module > with the full debuginfo and file still doesn't say anything about it... file's behavior changed (incompatibly) for ET_REL files, which .ko are. From revdfatherclark at urdun.cc Wed Jan 30 20:59:08 2008 From: revdfatherclark at urdun.cc (Revd. Fr.Peter Clark) Date: Wed, 30 Jan 2008 21:59:08 +0100 Subject: FOR YOUR ATTENTION ONLY,. Message-ID: OFFICE OF REVD.FR Peter Clark DIRECTOR SPECIAL DUTIES,UNITED NATIONS ORGANISATION IN CONJUNCTION WITH THE INTERNATIONAL MONETARY FUND WORLD BANK FACT-FINDING & SPECIAL DUTIES OFFICE LONDON UK. TEL: +447045711839. Dear Friend. I am Rev. Fr.Peter Clark. A senior staff with the World Bank fact finding & special duties office. I am writing you this letter based on the fact that cool penny is better than millions of dollars means it's better for one to live and die poor honest man than a rich dishonest one. I and the Chief security officer (CSO) of this organisation and have arranged with an officer in the computer section in person of Engineer Peter Cliff to bring out part of your total pending payment with reference number (LM-05-371) amounting to US$10 million. Why we did this is because according to information gathered from the bank?s/security computer, you have been waiting for a long time to receive this payment without success. As I found out that you have almost met all the statutory requirements in respect of your pending payment. The problem we feel you are having is that of interest groups. A lot of people are interested in your payment and those people are merely doing paper works with you and that explains why you receive different kinds of untrue fax and phone messages from different people everyday. Also we found out that some of the officials of the parastatals have been extorting a lot of money from you with the pretext of helping you receive your money. I can assure you this will keep happening if you do not do away with those officers. For security reasons you do not have to tell anybody that your have your payment on the way until the payment gets to you. The said payment is been arranged in a security-proof box weighing 75kg. In order to get this box shipped to you I and the (CSO) Yesterday went to this four courier companies Dhl, Ems, FedEx and Ups to make arrangements on how to get the box shipped to you by courier, but to no avail the above courier companies all made us to understand that they will have to open the box for inspection by the customs before shipment. This is something we want to avoid because this box is been padded with synthetic nylon and to open it you will have to cut the pad before you will meet the button that you will press to open the dial code-lock. There is no way you can open the box and be able to close it again because it was padded with machine. We told the courier services that the box contained film materials and when open will spoil the materials. we did not declare money because courier does not carry money. Today a friend of mine who is diplomat disclosed to me that there is a security courier service company that is specialised in sending diplomatic materials and information from one country to another, which also has diplomatic immunity and consignment such as this cannot be checked by any customs anywhere in the world. I have therefore met the official of the security courier service and concluded shipping arrangement with them, which they will commence as soon as I have your go ahead order. The diplomat who will be bring in this consignment to you is an expact and has been in this line of work for many years now so we have Notting to worry about. After all arrangements we have concluded that you must donate Five Hundred Thousand United States dollars (US$500,000.00) to any charity organisation I designate as soon as you receive your money. To this effect, you will send to us a promissory note for the donation along with your address where you will like the box to be delivered to by courier. Please maintain topmost secrecy as it may cause a lot of problems if found out that we are using this way to help you. You are advised not inform anyone about this until you received your money. Am helping you on this because something in me is tells me that you are an honest person. When you conclude this and you send our promise, we will help to ship the final part of your money to you. May God be with you as i wait for your response either through Fax or Email: Feel free to call me if you will like us to discuses more on this TEL: +447045711839. Yours Faithfully Revd. Fr.Peter Clark Director, Special Duties. UNO/WBF. From webmaster at equipashop.com.br Wed Jan 30 18:14:19 2008 From: webmaster at equipashop.com.br (webmaster at equipashop.com.br) Date: Wed, 30 Jan 2008 16:14:19 -0200 Subject: Coifa Message-ID: <200801302336.m0UNaLuc022476@mx3.redhat.com> An HTML attachment was scrubbed... URL: From jmorris at namei.org Thu Jan 31 00:16:52 2008 From: jmorris at namei.org (James Morris) Date: Thu, 31 Jan 2008 11:16:52 +1100 (EST) Subject: Update needed for SELinux kernel config Message-ID: Some SELinux changes have just been merged upstream, which include a bump in the SELinux policy version to support dynamic querying of policy capabilities. The new maximum supported policy version is 22, so we need this in .config: CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX_VALUE=22 -- James Morris From rev_paulbstn at worldbank.org Wed Jan 30 04:36:19 2008 From: rev_paulbstn at worldbank.org (rev_paulbstn at worldbank.org) Date: Wed, 30 Jan 2008 04:36:19 +0000 Subject: FUND CONSULTATION 2 Message-ID: FROM: OFFICE OF REV.FR PAUL BASTIAN, DIRECTOR, SPECIAL DUTIES UNITED NATIONS, IN CONJUNCTION WITH THE INTERNATIONAL MONETARY FUND,WORLD BANK SPECIAL DUTIES OFFICE:DAKAR,SENEGAL. TEL:+221-77-556-4607 ATTN: I am Rev.Fr Paul Bastian,a senior staff with the UN special duties office ;my office monitors and controls the affairs of all banks and financial institutions. I have before me list of funds and beneficiaries, which could not be transferred to some nominated accounts as these accounts have been identified either as ghost accounts, unclaimed deposits or over-invoiced sum etc. I have the opportunity to write you based on the instructions among others I received days ago from the officer in the computer section in person of Dr. Tony Kimber,to bring out part of your total pending payment with reference number (LM-02-341)amounting US$10million. The (Ten Million Dollars) is already arranged to be paid to you. A lot of people are interested in your payment and those people are merely doing paper works with you and that explains why you receive different kinds of untrue fax, email and phone messages from different people everyday. As I found out that you have almost met all the statutory requirements in respect of your pending payment. Also we found out that some of the officials of the parastatals have been extorting money from you with the pretext of helping you receive your money. I can assure you this will keep happening if you do not do away with those officers.I am the final signatory to any transfer or remittance of huge funds moving within banks both on the local and international levels. I am conditionally prepared to assist you get the money, practically after studying the part leading to this particular stage in the payment process in connivance with your local collaborators to conceal the authentic source of the funds.And my only condition for this unusual assistance is after all arrangements we have concluded that you must donate at least Four Hundred Thousand United States dollars (US$400,000.00) to any charity organization I designate as soon as you receive your money. To this effect, you will send to us a promissory note for the donation along with your full information. Call me on my private line below for instructions and further discussions on the payment. May almighty God bless you, Please maintain top confidentiality as it may cause a lot of problems if found out that we are using this way to help you until you received your money. When you conclude this we will help to transfer the final part of your money to you. Henceforth, write me on my private email address below. Yours Faithfully, Director, Special Duties.UNO/WBF. TEL:+221-77-556-4607 Email: rev_paulbstn at mixmail.com From zain at patxialcalde.com Thu Jan 31 15:27:37 2008 From: zain at patxialcalde.com (zain at patxialcalde.com) Date: Thu, 31 Jan 2008 20:57:37 +0530 Subject: Medical news! Message-ID: <47A1E8E9.2080804@patxialcalde.com> Make a step towards your happy future! http://85.192.189.111/uyqd/