Re: ULE Scheduler
At Wed, 13 Jun 2012 17:49:15 +0300, Daniel Kalchev wrote: On 12.06.12 16:08, Momchil Ivanov wrote: So the L2 cache is shared between both cores and hence it's size does not matter at all? If the cache is shared between both cores then it does not matter on which core the process runs, as long as data is in teh case. The cache size is irrelevant. Some CPUs have shared cache between cores, some don't. The ULE scheduler takes this into account, the 4BSD does not. Even if the ULE scheduler takes the CPU topology into consideration, if you only have two cores, it is almost guaranteed that processes will be switched between both, because the OS is running way more than two processes at the same time. Even with more cores... it is not guaranteed an computational process won't be 'bouncing'. Here is an example. Suppose you have an 8 core (or threads) CPU. If you happen to have an modern Ethernet controller, like the Intel 82576 (the igb driver in FreeBSD), then it will use up to 8 interrupt lines, by default routing them each to a different core. Then, if you have heavier network traffic, chances are that at any given moment all 8 interrupts might be fired and all 8 cores switched to service network traffic -- removing your computational process from the running queue. The next time it runs, it might run on any other core, especially if the cache is not shared. Of course, if you have sufficiently large number of CPUs, you can configure your system so that such things do not happen, like by limiting the number of cores the igb driver attaches to, and have some of the cores dedicated to 'only' running an computational task. There is however, very little sense doing so. OK, thank you for the explanation. Regards, Momchil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
At Tue, 12 Jun 2012 11:11:36 +0200 (CEST), Oliver Fromme wrote: ?? ?? momc...@xaxo.eu wrote: I compiled the same kernel with the 4BSD scheduler today and it seems that the processes jump accross cores too. What exactly is the problem that you're seeing? Do you have performance problems? If so, then they're probably *not* caused by processes jumping across cores. When my laptop said bye bye because of the heat I thougt it might be the scheduler, which was a mistake since I got 30 C reduction on full load after cleaning. Therefore, I don't think that there is any problem. I was just curious why both processes are hopping around, because I would naively think that should not happen. Note that I am neither software nor hardware expert, but a mere user of both. I tried the 4BSD scheduler just because Dough asked if I did. For me the question is resolved and I thank all of you for the replies. Have you read Daniel Kalchev's reply in this thread? He explained very well why that's not a problem usually. No, I haven't received that one. Regards, Momchil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
At Tue, 12 Jun 2012 14:03:10 +0200 (CEST), Oliver Fromme wrote: Momchil Ivanov momc...@xaxo.eu wrote: I was just curious why both processes are hopping around, because I would naively think that should not happen. I'll try to explain ... There are always many more processes and threads being executed beside the two CPU-bound ones that you see at the top of the top(1) display. For example, there are at least 15 threads inside the kernel (see ps -auxww) that are scheduled every now and then. Or look at vmstat -i output to see the interrupt statistics: Several hundred times per second, the interrupt handlers have to be executed. So, what happens is that an interrupt occurs (from a hardware clock, from a hard disk controller, from an input device, or anything else). Then your process is _removed_ from the core on which it is currently executing, and the interrupt handler starts executing. The same can happen on the second core at the same time, because different kernel threads can execute simultaneously (if they don't share resources). Now, if the interrupt handler on one of the two cores is done, your own process has a chance to be scheduled again. In this moment, it does not matter at all on which core it is going to be executed. The only difference is cache contents, but the first-level-caches are usually too small anyway. The ULE scheduler takes a lot of information into account when making the decision, including cache affinity (the 4BSD scheduler doesn't know about that at all). So the L2 cache is shared between both cores and hence it's size does not matter at all? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
At Thu, 07 Jun 2012 09:12:55 +0700, Erich wrote: Hi, On 07 June 2012 3:01:07 Момчил Иванов wrote: temperature. It was constantly increasing from about 33 C. I took a look at top and saw that both processes were wildly jumping accross the cores, i.e. CPU0 and CPU1. So before reading all the papers about the ULE scheduler and the source code, I would like to as a simple question: is it that stupid? maybe, maybe not. It could be that the difference is minor as the cache for both kernels is in the same chip. I mean, there are just 2 processes running (except of top, X and ... which should be scheduled occasionally) on 2 cores of one physical processor. Why sould each be scheduled on a different core each time? I did cpuset to pin each to a specific core and got to about a constant temperature of 72 C. I am affraid to cpuset -l 0,1 -p ... both of them since I might again get at 100 C. This would be the interesting point? Did it happen because of the dirt or because or the scheduler. Is there some remedy? I think that the only remedy available is the one you applied. Erich I've repeated the same experiment just now, setting both processes on both cores with cpuset. The temperature got to about 72-74 C, so the two small pieces of dirt that came out, the fresh thermal liquid and tightening the screws probably gave me 10 about C on idle (from 53 C down to 45 C) and 30 C on full load. I didn't expect that much... Though, it was strange seeing both processes hopping around... I will probably go back to the 4BSD scheduler if my laptop does another self-shutdown in the next few days as Doug suggested. Regards, Momchil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
At Fri, 8 Jun 2012 00:54:15 +0200, Martin Sugioarto wrote: [1 text/plain; UTF-8 (quoted-printable)] Am Thu, 07 Jun 2012 03:01:07 +0200 schrieb Момчил Иванов momc...@xaxo.eu: Is there some remedy? Hi, I remember this series, I've had a T60p and when I compiled world, I placed a fan in front of it to cool it down from 100°C. The difference with T60p was that it simply shut off reaching 101°C. The problem is the hardware, not FreeBSD. T60p and obviously T60, too, was made by some crazy people who had the idea to cool the CPU und the GPU under the same heat sink. The funny thing is that the GPU is running at 70°C all the time, because FreeBSD does not implement voltage regulation for the VGA chipset. The result is that the GPU warms up the CPU to at least 55°C while idle. If you want to have a cooler CPU implement power saving for the Radeon chipset there. Martin [2 signature.asc application/pgp-signature (7bit)] Hi, well, that is not true, I have been using the laptop since more than 4 years without any problems. The thing is that yesterday I had it docked and that seems to raise the idle temperature by about 10°C, so I get docked somewhere about 42°C when doing nothing computationally intensive: hw.acpi.thermal.tz0.temperature: 50.0C hw.acpi.thermal.tz1.temperature: 42.0C dev.cpu.0.temperature: 42.0C dev.cpu.1.temperature: 42.0C So I probably have to shift things around to give the dock a bit more room. However, the dust, the thermal liquid and the screws seem to have contributed to the temperature increase too. The GPU (Nvidia Quadro NVS 140M) might be an issue, nvidia-settings says 58°C (I am not running any fancy graphics) and I've seen it getting over 100-120°C before, when I am doing some opengl stuff. With the latter I mean, that I know how to intentionally kill it. Anyway, I have solved my problem and that seems to not be related to ULE at all. However, it was still surprising for me to find out how ULE schedules computationally intensive tasks. Regards, Momchil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Question about file system checks
On Friday 28 March 2008 16:26:16 Ivan Voras wrote: All were tested within the same time: 50 seconds. Details: the machine being tested was connected to a reporter machine via plain crossover cable, the reporter had a TCP server and the tested machine had a TCP client that run a tight loop of IO operations, single threaded, randomly choosing between creating files and directories, appending to them and changing (a random amount of data in a random position) them, then sending to the server a description (log) of each IO operation after it has been done. These were several Python scripts I wrote. I think that if you did different set of operations in the different test cases, you cannot compare the results. I think first you have to generate your random set of operations and then perform all test cases with it. After performing tests with several random sets of operations, you can draw some conclusions. Just my point of view. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb keyboard FreeBSD 7.0-BETA1
На Friday 02 November 2007 01:13:06 Paul Fraser написа: For the sake of the record, I also have this problem. Have you tried this one http://selasky.org/hans_petter/usb4bsd/index.html ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic after removing usb flash disk
На Thursday 16 August 2007 14:28:59 Artem Kuchin написа: Hello! I don't know if it really belongs to this list, since i have only tested on 7-CURRENT, but on the other hand 7-CURRENT is soon going to be stable. So here it goes: 1) insert usb flash disk 2) usbd detected it 3) mount it (mount -t msdosfs /dev/da1s1 /mnt) 4) simply pull the pen drive off the usb slot 5) /mnt mount pount is left 6) try to unmount it (umount /dev) I don't know to get all those kernel bright white messages in to a file, so i just attached a screenshot ;) -- Regards Artem It has been discussed recently, look on the archives for a thread with title removing external usb hdd without unmounting causes reboot?. I started it. -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B signature.asc Description: This is a digitally signed message part.
Re: removing external usb hdd without unmounting causes reboot?
On Thursday 19 July 2007 09:17:48 [LoN]Kamikaze wrote: Norberto Meijome wrote: On Wed, 18 Jul 2007 17:41:04 +0200 (CEST) Oliver Fromme [EMAIL PROTECTED] wrote: another work-around is to use the auto mounter daemon (amd(8)). It umounts file systems automatically that are not in use. Another nice feature of amd(8) is that you don't have to mount the file system either -- Simply plug the USB stick in, then access it, and amd(8) will automatically mount it for you. Now, something I dont understand - amd runs at user level, and it mounts filesystems, and nothing dies when the filesystems go away (other than the obvious cases for the applications trying to write to the FS in question). Doesn't amd , at some point , have to tell the kernel 'please mount this filesystem' here or there? Isn't the kernel STILL involved in all this? and why doesnt the kernel panic when the FS goes away? The trick is that amd unmounts the device after a couple of seconds, so when someone accidentally removes a usb drive, it doesn't really matter. Amd will simply fail to mount it on the next access. If you remove the device during or shortly after accessing it, it still will panic the system. What is then the reason for the kernel not being able to unmount a filesystem whose provider is no longer present? What in the process of unmounting denies unmounting a filesystem whose provider is no longer available? Why can the kernel not just inform all programs that files have to be closed and are unaccessible any more, then consider the fs as unmounted and remove any bits of it left in the VM. Why can kernel not just ignore interruped/pending writes to that fs, drop the data, return an error to the program that initiated the write and just go on. -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B pgpK94L1KnIM6.pgp Description: PGP signature
removing external usb hdd without unmounting causes reboot?
Hi, I am running FreeBSD 6.2-STABLE #11: Sat Jul 14 16:27:12 CEST 2007 and accidently unplugged the USB hub to which my external hdd together with a mouse were connected and this caused my machine to freeze for some seconds and then reboot. At that moment the hdd was mounted and I was playing music out of it. After that I tried to reproduce it :) so just plugged only the hdd directly, mounted it and started playing music files from it. When I unplugged the USB cable the same thing happened: short freeze, and then reboot. Is this expected behaviour? And is there some way to avoid the freeze and reboot? Thanks. -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
On Wednesday 18 July 2007 15:52:42 [LoN]Kamikaze wrote: Josh Paetzel wrote: On Wednesday 18 July 2007, Momchil Ivanov wrote: Hi, I am running FreeBSD 6.2-STABLE #11: Sat Jul 14 16:27:12 CEST 2007 and accidently unplugged the USB hub to which my external hdd together with a mouse were connected and this caused my machine to freeze for some seconds and then reboot. At that moment the hdd was mounted and I was playing music out of it. After that I tried to reproduce it :) so just plugged only the hdd directly, mounted it and started playing music files from it. When I unplugged the USB cable the same thing happened: short freeze, and then reboot. Is this expected behaviour? And is there some way to avoid the freeze and reboot? Thanks. Yes, it's expected behavior. The workaround is to not unplug mounted devices. (There's nothing special about USB here, if you unplugged an IDE drive you'd get the same behavior) Wouldn't it make some sense not to panic if mounted devices that are in sync get removed? A few applications might get in trouble, but that's hardly a reason to bring a whole system down. I don`t know how things work, but shutting down the system when some mounted fs is no longer present seems like the wrong thing to me. It`s surely safe :) just bring everything down in order to ensure not messing things ups. But nowadays there are a lot of USB devices and umounting every time is something that one is surely going to forget once and ooops everyting goes down. If the same thing happens when a network fs is mounted (say NFS or SMBFS) and then becomes unavailable due to network outages (wireless connections break easily compared to cable connections, and nowadays the former become popular), then I think it should be fixed. Windows doesn`t reboot if you unplug the usb or network cable, which I think is the right way of handling these kind of situations. Idea: do something like umount -f when a fs becomes unavailabe, just tell every program that files are unaccessible? I don`t have the programming skills and knowledge of how freebsd works, that`s why I can only help with feedback and ideas :) Shutting down the system without user`s desire seems like a problem to me, regardless of the reason. And problems are there to be solved. -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B pgpIlHaW3FprO.pgp Description: PGP signature
Re: removing external usb hdd without unmounting causes reboot?
On Wednesday 18 July 2007 17:41:04 Oliver Fromme wrote: As Josh wrote, it's expected. The problem is known to exist for a long time already (probably as long as FreeBSD itself exists), and if there was an easy solution, certainly someone would have fixed it. Just remember to always umount first, and you're safe. In the early 90s I panicked a FreeBSD machine by removing a floppy disk that was mounted. I did that mistake only once -- afterwards I always remembered. If you have problems remembering, another work-around is to use the auto mounter daemon (amd(8)). It umounts file systems automatically that are not in use. Another nice feature of amd(8) is that you don't have to mount the file system either -- Simply plug the USB stick in, then access it, and amd(8) will automatically mount it for you. Best regards Oliver I started the thread just because it hit me today. I wanted to disconnect my mouse and forgot that the hdd is connected to the same hub, I realized that after having unplugged the usb hub and saw the system freeze. I know that this has been an issue for a long time. With cdroms it`s easy, the tray won`t open until you umount the cd fs, floppies. nowadays they have been replaced by usb sticks, but they have no trays as cdroms do :) moreover people use other usb storages too and unplugging those is just as simple as unpluging the cable. I think this is a critical problem and needs to be addressed, avoiding it doesn`t solve it. As technology advances I think FreeBSD has to advance too. You said you paniced a system in the early 90s, which is more than 10 years from now. In the past floppy disks were maybe the only problem, but nowadays as storage is cheap more and more people use USB storage devices, and these are easy to unplug. It`s even worse if you have a laptop, since it`s easier to connect everything to a hub (mouse, hdds, other usb stuff) and connect/disconnect it. In the days before common storage devices (hard drives) where fixed inside the computer`s case, so unpluging a hard drive when the computer was running was considered as insane, so panicing is ok. Nowadays things have changed. USB (maybe Firewire too, have no experience with that) offers a simple way to connect/disconnect devices to your computer (here I have to note: not just one!), having a laptop and 1,2,3 or even more external storage devices is something usual. That`s why I think this particular problem needs to be addressed. Thanks for the tip about amd(8) I will give it a try. -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B pgpPIKc8k2BdR.pgp Description: PGP signature
Re: removing external usb hdd without unmounting causes reboot?
On Wednesday 18 July 2007 19:34:06 Mark Linimon wrote: On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote: Bottom line here is that the kernel panics when removing a USB device that has filesystems mounted. s/USB // Just a dumb question: what does umount -f does? And doing something like that when a fs goes away shouldn`t fix it? If the problem is in general with a file system, regardless of the provider, then what does one do when a mounted smbfs becomes unavailable due to remote host down, no route to host or some other network related problems? Same question for NFS mounted filesystems? -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B pgpfXbuzcbviO.pgp Description: PGP signature
Re: removing external usb hdd without unmounting causes reboot?
On Wednesday 18 July 2007 21:03:10 Josh Paetzel wrote: On Wednesday 18 July 2007, Mark Linimon wrote: On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote: Bottom line here is that the kernel panics when removing a USB device that has filesystems mounted. s/USB // I also have a hard time believing that the reason it hasn't been fixed is because there isn't an easy fix. I'm under the impression it hasn't been fixed because either no one cares enough to fix it (using the workaround as a scapegoat excuse), or because the majority of people do not use USB-based storage devices. The reason is not the USB stack; the reason (IIRC) is that the FreeBSD VM was written with the default assumption that Devices Never Go Away. A large rewrite, I'm told, will be needed to fix this, and the code is convoluted and tricky. No one finds the situation acceptable; introducing the scapegoat word isn't going to win you any support. The problem is not a weekend's worth of work to fix, nor does it have anything to do with avoidance by one particular maintainer, which you apparently had encountered before. mcl Panicing really is the right thing to do with the current architecture. Not panicing when a mounted filesystem disappears runs the risk of corrupting other mounted filesystems. Mark is entirely correct, FreeBSD faces an architecture problem here in that the vm and filesystems we have today were not designed in an era when they could just disappear from a running system. The BSD way isn't to apply a quick and dirty little hack to fix the 'problem', it's to design the system properly. And this is assuming a quick and dirty hack even exists. The other problem you're running in to with UFS anyways is that there is no chance to 'unmount' the filesystem when you disconnect the drive. By the time anything has a chance to realize it's gone it's too late. Whether the disk is in the middle of a write, still has buffers to be written out, or is perfectly clean and needs to just be marked as such by the time the OS realizes any of that needs to be done the drive is no longer physically connected to the computer. I think you are missing the point here and it is that the drive is already gone, so you do not have to care about it. The state of the drive`s filesystem is of no interest since you cannot to anything to change it any more. The point is that the drive is gone. If you were in the middle of a write, you just return an error (like your disk is going physically bad/ some broken cable issue... for instance) and forget about the data you wanted to write, the drive is not there any more. Maybe I am naive and uneducated enough (don`t know how freebsd does things, nor am I a programmer) but I will give my 2 stotinki here. The most natural way for me seems to be that the OS should just return errors to the programs trying any I/O on that drive. May be when a drive is unplugged the OS has to mark it and the mounted file systems as not being there until all opened files on it are closed, return errors for all I/O except for closing opened files. And when all files are closed consider the fs as unmounted and remove the drive from the kernel. This is my idea of how things should be done. Ensuring that a file system is in a consistent state after drive disconnect is something completely different (wanted to discuss just disconnecting devices, not filesystems that can be disconnected without unmount, not ensuring fully operational file system even it a case of disconnected drive). One can try to implement something here (as mentioned in some of the replies), but not necessary. If the user has unpluged the device without unmounting it first he might be left with a broken file system on that drive, we cannot do anything, so we should not care about it, it`s his mistake and his fs fucked up. The point is that unpluging should not lead to system crash, which is in my opinion critical system error. I as user I should be able to unplug any external device without crashing the OS. Doing this and thus leaving me with a broken filesystem or some other device issues should be considered my error. Thus I should learn the hard way to unmount first. Designing a filesystem or some hacks to ensure consistent state after disconnect should not be in the scope of this thread and problem, I think. What might need to happen is a redesign of the vm subsystem so that it can safely deal with mounted filesystems going away, and designing a filesystem that doesn't need to be unmounted specifically for removeable devices. Doesn't sound trivial to me. Or You can just not remove devices with mounted filesystems from your computer. -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B ___ freebsd-stable@freebsd.org mailing
Re: atapicam and cd-rw problem, no cd0 but acd0 some error
On Thursday 14 June 2007 12:42:20 Tom Evans wrote: The error message is benign - the controller tries to send a command to the device, the device doesn't support it, so you get the error message. That's all, everything else should work. Do you load or compile into your kernel device scbus device cd I have missed this one ^^, I`ve checked my config today and noticed that I`ve left that device cd commented, because it used to hang my system before when trying to access the cd-rw drive. I`ve uncommented it and now it works, I have /dev/cd0, though I still see some errors about /dev/acd0 acd0: FAILURE - MODE_SELECT_BIG ILLEGAL REQUEST asc=0x26 ascq=0x00 sks=0x00 0x00 0x0c acd0: FAILURE - MODE_SELECT_BIG ILLEGAL REQUEST asc=0x26 ascq=0x00 sks=0x00 0x00 0x0c acd0: FAILURE - MODE_SENSE_BIG ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x02 acd0: FAILURE - MODE_SELECT_BIG ILLEGAL REQUEST asc=0x26 ascq=0x00 sks=0x00 0x00 0x0c acd0: FAILURE - MODE_SELECT_BIG ILLEGAL REQUEST asc=0x26 ascq=0x00 sks=0x00 0x00 0x0c acd0: FAILURE - READ_BUFFER ILLEGAL REQUEST asc=0x20 ascq=0x00 acd0: FAILURE - START_STOP ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x04 acd0: FAILURE - MODE_SENSE_BIG ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x02 acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x00 acd0: FAILURE - MODE_SENSE_BIG ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x02 I have successfully burned a cd with k3b and mounted it afterwards, everything seems to be there. Sorry for the noise. device atapicam atapicam allows you to access ATAPI devices through the SCSI subsystem, so you must ensure that you have a SCSI subsystem to access them through. Cheers Tom -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B pgp1f75s18hWe.pgp Description: PGP signature
atapicam and cd-rw problem, no cd0 but acd0 some error
Hi guys, I am running 6-STABLE as of today and I cannot use the CD-RW on my IBM T40 to burn CDs. When I put atapicam_load=YES in loader.conf or compile it in the kernel I see the following error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 and no /dev/cd0 is created. I don`t see the above error without atapicam loaded or in kernel. This is not something new, I haven`t been able to get /dev/cd0 since more than a month following 6-STABLE, don`t know if it ever worked on 6 or 6.x, but I certainly cannot get it to work on 6-STABLE. Any help would be appreciated :) I would be happy ot be able to burn CDs. I have acd0: CDRW TOSHIBA DVD-ROM SD-R9012/1121 at ata1-master UDMA33 and camcontrol shows: TOSHIBA DVD-ROM SD-R9012 1121at scbus2 target 0 lun 0 (pass1) Thanks -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B pgp9CYLqGQLU5.pgp Description: PGP signature
