Bug 174537 - FireWire not working in recent 2.6.14 kernels
FireWire not working in recent 2.6.14 kernels
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-29 15:40 EST by Darren Brierton
Modified: 2008-08-02 19:40 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-05 08:34:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Darren Brierton 2005-11-29 15:40:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
FireWire does not appear to be working in the 2.6.14 FC4 kernels. My IOMEGA external HDD is not recognised and mounted, despite working flawlessly in the 2.6.13 kernels.

Version-Release number of selected component (if applicable):
kernel-2.6.14-1.1644_FC4

How reproducible:
Always

Steps to Reproduce:
1. Boot with 2.6.14 kernel
2. Attach FireWire device.
  

Actual Results:  Nothing.

Expected Results:  Drive should have been recognised and mounted.

Additional info:
Comment 1 Les Mikesell 2005-11-30 13:17:23 EST
I see the same with a Western Digital external firewire drive.  Note that it is
not a problem with firewire itself or even the scsi emulation layer - the disk
does show up in /proc/scsi/scsi.  However no /dev/sd? devices appear and no
partitions are recognized.
Comment 2 André Fettouhi 2005-12-02 13:00:37 EST
Is there any fix to get the firewire drive working? I have the same problem with
my Maxtor 200 GB firewire HD.

Regards

André Fettouhi
Comment 3 Les Mikesell 2005-12-02 14:00:37 EST
Updates don't delete your old kernels.  Pick 2.6.13-1.1532_FC4 during boot or
edit /etc/grub.conf to make it your default again.
Comment 4 Leon Fauster 2005-12-08 09:50:15 EST
So far i noticed - everything went well with the recognition of the fw hd.
things that are broken: making entries to fstab and dirs into /media etc.
everything works okay befor 2.6.14... kernels.
Comment 5 raxet 2005-12-09 20:27:04 EST
I can't get my Sony DRX-710UL firewire CD-RW drive detected either.
Comment 6 Kyle Pablo 2005-12-14 16:03:07 EST
same here...doesnt recognize my externel firewire hdd...on all kernels after
2.6.13-1.1532....
Comment 7 Kyle Pablo 2005-12-15 13:35:38 EST
oh...im on an x86_64 machine and it doesnt work.
Comment 8 Darren Brierton 2005-12-18 02:28:07 EST
This is not resolved in the latest kernel-2.6.14-1.1653_FC4 update. Is anyone
from Red Hat even reading this bug report?
Comment 9 Pete Zaitcev 2005-12-18 18:52:44 EST
Darren: yes.
Comment 10 Darren Brierton 2005-12-18 22:42:33 EST
(In reply to comment #9)
> Darren: yes.

Pete: sorry if my question sounded terse. That wasn't intended at all. But I was
wondering why we hadn't had a comment asking for moreinfo (I freely admit my bug
report is lacking in info, but I wasn't sure what was needed), or just something
like "we are aware of what is going on and think a patch upstream will fix it".

I really hope I didn't come across as a petualant user demanding stuff ...

Glad to know you're on the case.
Comment 11 Leon Fauster 2005-12-19 17:12:48 EST
Addition to my comment 4:

SMP System with kernel-smp-2.6.14-1.1644_FC4 and hotplug-2004_09_23-7.

After switching fw-hd on:

kernel: ohci1394: fw-host0: SelfID received, but NodeID invalid (probably new
bus reset occurred): 0800FFC0
kernel: ieee1394: Error parsing configrom for node 0-00:1023
ieee1394.agent[4937]: ... no drivers for IEEE1394 product 0x/0x/0x
ieee1394.agent[4946]: ... no drivers for IEEE1394 product 0x/0x/0x
kernel: sbp2: $Rev: 1306 $ Ben Collins <bcollins@debian.org>
kernel: ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1)
kernel: ieee1394: sbp2: Try serialize_io=0 for better performance
kernel: scsi2 : SCSI emulation for IEEE-1394 SBP-2 Devices
kernel: ieee1394: sbp2: Logged into SBP-2 device
kernel:   Vendor: ST316002  Model: 3A                Rev:     
kernel:   Type:   Direct-Access-RBC                  ANSI SCSI revision: 04
kernel: SCSI device sdd: 312581808 512-byte hdwr sectors (160042 MB)
kernel: sdd: asking for cache data failed
kernel: sdd: assuming drive cache: write through
kernel: SCSI device sdd: 312581808 512-byte hdwr sectors (160042 MB)
kernel: sdd: asking for cache data failed
kernel: sdd: assuming drive cache: write through
kernel:  sdd: sdd1 sdd2
kernel: Attached scsi disk sdd at scsi2, channel 0, id 0, lun 0
scsi.agent[4989]: enclosure at
/devices/pci0000:00/0000:00:0b.0/0000:02:0b.0/fw-host0/0050770e00071002/0050770e00071002-0/host2/target2:0:0/2:0:0:0
kernel: Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0
kernel: Attached scsi generic sg1 at scsi0, channel 0, id 1, lun 0,  type 0
kernel: Attached scsi generic sg2 at scsi0, channel 0, id 2, lun 0,  type 0
kernel: Attached scsi generic sg3 at scsi0, channel 0, id 3, lun 0,  type 5
kernel: Attached scsi generic sg4 at scsi2, channel 0, id 0, lun 0,  type 14


Looking into my old rotated log files: 

It doesnt look like that this "ieee1394: Error parsing configrom"
message appears befor.

Thanks Pete

PS: If more info is necessary ...
Comment 12 Darren Brierton 2006-01-11 09:46:57 EST
This is still a problem for me with kernel-2.6.14-1.1656_FC4.

Is there something specific I/we can do/provide to help with this problem? I
have a feeling that we're not seeing a resolution of this because you lack the
necessary info or hardware to isolate what the problem is. I'm sure many/most of
us experiencing this problem would be only to glad to help more if only we knew
what was needed from us. I actually need my FireWire HDD for work, so I can't
use any 2.6.14-* kernels until this is resolved.
Comment 13 Dave Jones 2006-01-12 20:04:02 EST
does the 2.6.15 kernel in updates-testing work any better ?
Comment 14 Darren Brierton 2006-01-13 09:25:42 EST
(In reply to comment #13)
> does the 2.6.15 kernel in updates-testing work any better ?

I installed kernel-2.6.15-1.1824_FC4.i686 from updates-testing. No improvement.

Booted with FireWire HDD unattached. This what tail -f /var/log/messages shows
upon attaching FireWire HDD:

Jan 13 14:28:15 excession kernel: ohci1394: fw-host0: SelfID received, but
NodeID invalid (probably new bus reset occurred): 0000FFC0
Jan 13 14:28:15 excession ieee1394.agent[3156]: ... no drivers for IEEE1394
product 0x/0x/0x
Jan 13 14:28:15 excession ieee1394.agent[3165]: ... no drivers for IEEE1394
product 0x/0x/0x
Jan 13 14:28:15 excession kernel: SCSI subsystem initialized
Jan 13 14:28:15 excession kernel: sbp2: $Rev: 1306 $ Ben Collins
<bcollins@debian.org>
Jan 13 14:28:15 excession kernel: ieee1394: sbp2: Driver forced to serialize I/O
(serialize_io=1)
Jan 13 14:28:15 excession kernel: ieee1394: sbp2: Try serialize_io=0 for better
performance
Jan 13 14:28:15 excession kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
Jan 13 14:28:16 excession kernel: ieee1394: sbp2: Logged into SBP-2 device
Jan 13 14:28:17 excession kernel:   Vendor: IC35L120  Model: AVV207-0          Rev:
Jan 13 14:28:17 excession kernel:   Type:   Direct-Access-RBC                 
ANSI SCSI revision: 04
Jan 13 14:28:17 excession scsi.agent[3207]: enclosure at
/devices/pci0000:00/0000:00:1e.0/0000:02:01.2/fw-host0/00d0b87500007594/00d0b87500007594-0/host0/target0:0:0/0:0:0:0
Jan 13 14:28:17 excession kernel:  0:0:0:0: Attached scsi generic sg0 type 14

Comment 15 Darren Brierton 2006-01-13 09:39:29 EST
For the sake of comparison with my comment #14, booting with
kernel-2.6.13-1.1532_FC4.i686 with FireWire HDD unattached. Output of tail -f
/var/log/messages on attaching FireWire HDD:

Jan 13 14:42:52 excession kernel: ohci1394: fw-host0: SelfID received, but
NodeID invalid (probably new bus reset occurred): 0000FFC0
Jan 13 14:42:52 excession ieee1394.agent[3930]: ... no drivers for IEEE1394
product 0x/0x/0x
Jan 13 14:42:52 excession ieee1394.agent[3941]: ... no drivers for IEEE1394
product 0x/0x/0x
Jan 13 14:42:53 excession kernel: SCSI subsystem initialized
Jan 13 14:42:53 excession kernel: sbp2: $Rev: 1306 $ Ben Collins
<bcollins@debian.org>
Jan 13 14:42:53 excession kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
Jan 13 14:42:54 excession kernel: ieee1394: sbp2: Logged into SBP-2 device
Jan 13 14:42:54 excession kernel:   Vendor: IC35L120  Model: AVV207-0          Rev:
Jan 13 14:42:54 excession kernel:   Type:   Direct-Access                     
ANSI SCSI revision: 06
Jan 13 14:42:54 excession scsi.agent[3983]: disk at
/devices/pci0000:00/0000:00:1e.0/0000:02:01.2/fw-host0/00d0b87500007594/00d0b87500007594-0/host0/target0:0:0/0:0:0:0
Jan 13 14:42:54 excession kernel: SCSI device sda: 241254720 512-byte hdwr
sectors (123522 MB)
Jan 13 14:42:54 excession kernel: sda: asking for cache data failed
Jan 13 14:42:54 excession kernel: sda: assuming drive cache: write through
Jan 13 14:42:54 excession kernel: SCSI device sda: 241254720 512-byte hdwr
sectors (123522 MB)
Jan 13 14:42:54 excession kernel: sda: asking for cache data failed
Jan 13 14:42:54 excession kernel: sda: assuming drive cache: write through
Jan 13 14:42:54 excession kernel:  sda: sda1
Jan 13 14:42:54 excession kernel: Attached scsi disk sda at scsi0, channel 0, id
0, lun 0
Jan 13 14:42:55 excession fstab-sync[4016]: added mount point /media/IOMEGA_HDD
for /dev/sda1
Jan 13 14:42:55 excession kernel: SELinux: initialized (dev sda1, type vfat),
uses genfs_contexts
Comment 16 Les Mikesell 2006-01-17 12:57:54 EST
Same here with kernel-2.6.15-1.1824_FC4.  The drive is recognized as scsi
generic sgo and shows up in /proc/scsi/scsi but the sbp2 layer doesn't make the
/dev/sd? device or find partitions.
Comment 17 Les Mikesell 2006-01-17 14:04:27 EST
By the way, the same drive above does work when connected via USB instead of
firewire.  It shows the same in /proc/scsi/scsi either way but with USB the
/dev/sd devices are created and if the drive is connected at boot time the /md
device on the drive is also detected.
Comment 18 André Fettouhi 2006-01-23 07:02:42 EST
Has this been fixed yet for example in FC5 (Rawhide)?

Kind Regards

André Fettouhi
Comment 19 Dave Hawkes 2006-01-26 19:58:55 EST
I have the same problem with 4 pyro firewire cases. However one of them also
supports USB and if I connect this drive via USB instead, then it is detected
AND all the other firewire drives also suddenly become visible and work
perfectly! I can then see /dev/sda through to /dev/sdd has been created.

I haven't tried it, but one workaround may be just to plug in a small USB flash
drive to force firewire detection...
Comment 20 Bill McGonigle 2006-01-26 23:37:26 EST
I had similar troubles.  Nothing would work right on the lastest FC3 kernel.  I
upgraded to FC4 and things recognized better, but like many of the comments here
there was no sda,sdb.

I manually did an modprobe sd_mod and then everything recognized.  That's a hot
plug job, right?  (not totally sure)

I do get a bunch of these in dmesg now:
  ieee1394: unsolicited response packet received - no tlabel match
but the drives work perfectly.

My setup is listed here:
  http://www.mail-archive.com/gnhlug-discuss@mail.gnhlug.org/msg12590.html
Comment 21 Dave Jones 2006-02-02 19:50:58 EST
if it started working when you loaded sd_mod, then that's a problem with udev.
Comment 22 Darren Brierton 2006-02-03 09:09:56 EST
FYI, just tested again with latest kernel and udev from updates-released
(kernel-2.6.15-1.1830_FC4, udev-071-0.FC4.2) and this is still not working.

Comment 23 André Fettouhi 2006-02-05 11:04:38 EST
Just tested my firewire with the latest version of the kernel and udev for FC4
and latest hal from nrpms.net and now after many weeks my firewire works again.
I can see my Maxtor 200 GB disk. I didn't have to load sb_mod. Many thanks.

Regards

André Fettouhi
Comment 24 Les Mikesell 2006-02-06 19:05:00 EST
Mine is working again with kernel.i686 2.6.15-1.1830_FC4 and whatever else came
along in a yum update - including udev.i386 071-0.FC4.2.  Mine is a WD 250 gig
and  if it is connected during a reboot the md device on it is recognized too.
Comment 25 Kyle Pablo 2006-02-07 16:44:24 EST
Interesting. It does not work on mine after the update to 2.6.15-1_1830 on an
x86_64 box.
Comment 26 Bill McGonigle 2006-02-07 17:29:50 EST
For another data point - on mine I now get sda and sdb without having to insmod
sd_mod (great progress) but I don't get any RAID autodetection.  There is some
talk about that on debian here:  
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=273182
I'm not sure if they sent those patches upstream such that we'd see them trickle
down to fedora core.
Comment 27 Les Mikesell 2006-02-07 18:34:04 EST
I don't get RAID autodetection on a hotplug, but I do on a reboot. I no longer
have the matching internal drive in the machine where I am testing so I am not
sure if the detection happens at the right time to pair the mirrors up, but it
does come up as an md device with one member present.
Comment 28 Kyle Pablo 2006-02-08 15:18:33 EST
hello,

i upgraded to kernel-2.6.15-1.1831 on an x86_64 and this is what i get:

ieee1394: Node resumed: ID:BUS[0-00:1023]  GUID[0030e001e0000048]
scsi3 : SCSI emulation for IEEE-1394 SBP-2 Devices
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
  Vendor: ST340083  Model: 2A                Rev: 3.03
  Type:   Direct-Access-RBC                  ANSI SCSI revision: 04
SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB)
sdb: asking for cache data failed
sdb: assuming drive cache: write through
SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB)
sdb: asking for cache data failed
sdb: assuming drive cache: write through
 sdb: sdb1
sd 3:0:0:0: Attached scsi disk sdb
sd 3:0:0:0: Attached scsi generic sg1 type 14

but the device is not accessible/mounted.

this is what i get whwn turning it off:

ieee1394: Node changed: 0-01:1023 -> 0-00:1023
ieee1394: Node suspended: ID:BUS[0-00:1023]  GUID[0030e001e0000048]

So it sees it but i cannot access it.  i tried modprobe sd_mod and that did not
help.
Comment 29 Les Mikesell 2006-02-08 19:40:46 EST
What does that last 'not accessible' mean?  Can you, as root:
fdisk -l /dev/sdb
and see partitions?  If so, the kernel has done its job and if you have a
suitable filesystem on the partition you should be able to mount it.
Comment 30 Kyle Pablo 2006-02-08 21:16:25 EST
hello,

i did fdisk -l /devsdb and /dev/sdb and it return a prompt.  The device does
come up in dmesg as:

sbp2: $Rev: 1306 $ Ben Collins <bcollins@debian.org>
ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1)
ieee1394: sbp2: Try serialize_io=0 for better performance
scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
  Vendor: ST340083  Model: 2A                Rev: 3.03
  Type:   Direct-Access-RBC                  ANSI SCSI revision: 04
SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB)
sdb: asking for cache data failed
sdb: assuming drive cache: write through
SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB)
sdb: asking for cache data failed
sdb: assuming drive cache: write through
 sdb: sdb1
sd 1:0:0:0: Attached scsi disk sdb
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: Attached scsi generic sg1 type 14

so i have no idea when it cannot see it.  it works on 2.6.13 but not of the
2.6.14's. its formated as a ext3.
Comment 31 Bill McGonigle 2006-02-09 15:30:09 EST
The original problem here is now WFM on 2.6.15 for my hardware.  I've filed bug
180708 about the md autoassembly problem which really seems like a different issue.
Comment 32 Kyle Pablo 2006-02-09 20:28:00 EST
What else can i check to see why firewire is not auto loading on boot up for my
x86_64 box?  The kernel sees it.
Comment 33 Stefan Richter 2006-02-14 13:49:37 EST
I am not an FC user myself, therefore cannot be entirely sure where the problem
really is. However I think because of reasons given for another bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175998#c15 , there is
probably the loading of sd_mod by some userspace tool (hotplug script?) missing.
http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=112129848913652
Comment 34 Darren Brierton 2006-04-06 11:34:44 EDT
I am still experiencing this problem with kernel-2.6.16-1.2069_FC4.i686. On
attaching external IOMEGA FireWire 120GB drive I see this in /var/log/messages:

Apr  6 16:33:47 excession kernel: ohci1394: fw-host0: SelfID received, but
NodeID invalid (probably new bus reset occurred): 0000FFC0
Apr  6 16:33:48 excession kernel: scsi1 : SBP-2 IEEE-1394
Apr  6 16:33:49 excession kernel: ieee1394: sbp2: Logged into SBP-2 device
Apr  6 16:33:49 excession kernel:   Vendor: IC35L120  Model: AVV207-0          Rev:
Apr  6 16:33:49 excession kernel:   Type:   Direct-Access-RBC                 
ANSI SCSI revision: 04
Apr  6 16:33:49 excession kernel: SCSI device sda: 241254720 512-byte hdwr
sectors (123522 MB)
Apr  6 16:33:49 excession kernel: sda: Write Protect is off
Apr  6 16:33:49 excession kernel: SCSI device sda: drive cache: write back
Apr  6 16:33:49 excession kernel: SCSI device sda: 241254720 512-byte hdwr
sectors (123522 MB)
Apr  6 16:33:49 excession kernel: sda: Write Protect is off
Apr  6 16:33:49 excession kernel: SCSI device sda: drive cache: write back
Apr  6 16:33:49 excession kernel:  sda: sda1
Apr  6 16:33:49 excession kernel: sd 1:0:0:0: Attached scsi disk sda
Apr  6 16:33:49 excession kernel: sd 1:0:0:0: Attached scsi generic sg0 type 14
Apr  6 16:33:49 excession scsi.agent[3530]: enclosure at
/devices/pci0000:00/0000:00:1e.0/0000:02:01.2/fw-host0/00d0b87500007594/00d0b87500007594-0/host1/target1:0:0/1:0:0:0
Comment 35 Stefan Richter 2006-04-06 15:36:15 EDT
Darren, this is obviously not a kernel problem. The whole stack of drivers
(ohci1394--ieee1394--sbp2--scsi_mod--sd_mod) is recognizing the device. It
should be possible to manually mount the partition sda1. Automount by HAL or
similar userspace helpers requires a small update of those helpers as described
in comment #33.

(Since Linux 2.6.14, the sysfs interface of scsi_mod reports type 14 instead of
type 0 for RBC disks such as most FireWire disks. See how scsi.agent prints
"enclosure" as device typ in your log. This is because some old scripts wrongly
associate "enclosure" with type 14 instead of type 13.)
Comment 36 Darren Brierton 2006-04-06 21:02:27 EDT
Stefan, thanks for the info. I'm no expert but what you said makes perfect
sense. However, it is still a bug. Only perhpas not a kernel bug. Should we
reassign this to a different component? I'm not upgrading to FC5 for at least a
month, so I'm stuck with this problem for a bit longer. When the kernels got
upgraded to kernel 2.6.14 clearly something else should have been upgraded along
with it -- HAL or something -- and wasn't. So, kernel guys, you'll be glad to be
rid of this one. Who should we assign it to?
Comment 37 Stefan Richter 2006-04-07 02:37:12 EDT
While all people mention HDDs, comment #5 refers to a CD-RW. This would be a
different bug since the type information of CD-RWs (actually the same type
identifier as CD-ROMs) did not change. If the submitter of comment #5 is still
reading this: Please try a newer kernel. There were other device recognition
problems fixed in Linux 2.6.15.

The HDD related problems obviously result (or resulted) from
 - userspace helpers not loading sd_mod for SCSI device type 14,
 - userspace helpers not automounting filesystems on SCSI devices of type 14.
Exactly which userspace helper(s) are responsible is unknown to me since I am
not familiar with FC's relevant infrastructure --- /etc/hotplug.d scripts, udev
scripts, HAL...

(PS: Of course the root of the problems is the change in the kernel's sysfs
interface, but as I mentioned elsewhere, that won't be reverted in the kernel.
Alas this is a frequent issue with sysfs. Luckily, an update of userspace to use
type 14 for HDDs in addition to type 0 will be safe with newer *and older*
kernels. The old association of type 14 with enclosures has always been wrong
but without effect.)
Comment 38 Dave Jones 2006-09-16 22:29:42 EDT
[This comment added as part of a mass-update to all open FC4 kernel bugs]

FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel.  As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
to FC5.

Please retest with Fedora Core 5.

Thank you.
Comment 39 Dave Jones 2006-10-16 17:37:23 EDT
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.
Comment 40 Dave Jones 2006-11-24 17:07:36 EST
This bug has been mass-closed along with all other bugs that
have been in NEEDINFO state for several months.

Due to the large volume of inactive bugs in bugzilla, this
is the only method we have of cleaning out stale bug reports
where the reporter has disappeared.

If you can reproduce this bug after installing all the
current updates, please reopen this bug.

If you are not the reporter, you can add a comment requesting
it be reopened, and someone will get to it asap.

Thank you.
Comment 41 Dave Jones 2006-11-24 17:09:39 EST
This bug has been mass-closed along with all other bugs that
have been in NEEDINFO state for several months.

Due to the large volume of inactive bugs in bugzilla, this
is the only method we have of cleaning out stale bug reports
where the reporter has disappeared.

If you can reproduce this bug after installing all the
current updates, please reopen this bug.

If you are not the reporter, you can add a comment requesting
it be reopened, and someone will get to it asap.

Thank you.
Comment 42 Jon Stanley 2008-02-05 08:34:55 EST
Closing since there was an error in previous mass-close and they remained in
NEEDINFO.

Note You need to log in before you can comment on or make changes to this bug.