Re: kld problem ? (was: Re: MSDOSFS wastes 256k when nothing is mounted!)
- Original Message -
From: Hiten Pandya [EMAIL PROTECTED]
To: Alexey Zelkin [EMAIL PROTECTED]
Cc: Poul-Henning Kamp [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, February 10, 2003 12:38 PM
Subject: Re: kld problem ? (was: Re: MSDOSFS wastes 256k when nothing is
mounted!)
On Sun, Feb 09, 2003 at 10:16:21PM +0200, Alexey Zelkin wrote the words in
effect of:
hi,
On Sun, Feb 09, 2003 at 08:39:59PM +0100, Poul-Henning Kamp wrote:
/*ARGSUSED*/
int
msdosfs_init(vfsp)
struct vfsconf *vfsp;
{
dehashtbl = hashinit(desiredvnodes/2, M_MSDOSFSMNT, dehash);
mtx_init(dehash_mtx, msdosfs dehash, NULL, MTX_DEF);
return (0);
}
BTW, it reminds me a problem I found last month. If you've MSDOSFS
compiled in kernel and try to load msdosfs.ko with loader -- then
you're 100% will hit into 'mutex already initialized' (or something
like that) panic later in boot process. (i.e. msdosfs_init() is called
twice for some reason)
I not sure if it's applicable to KLDs at all or to msdosfs only.
This also happens when the Linux kernel module is loaded twice.
Cheers.
I've seen this occur with at least one device/pseudodevice module before: if
I both compiled itinto my kernel and have it loaded in /boot/loader.conf, my
machine panics almost immediately.
At the time I just assumed I was being a moron for trying to load the same
driver twice, two different ways, and disabled the kld. If this isn't
supposed to happen I'll go back and try to find the modules that gave me
problems.
(I *think* it was either random.ko or procfs.ko).
--Mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
postfix equiv. of sendmail's -bH?
I upgraded my system last night to the latest -CURRENT and noticed a change in the daily mail cleanup. Unfortunately, I'm not running sendmail, so now I'm getting: Removing stale entries from sendmail host status cache: sendmail: fatal: unsupported: -bH Does anyone know if there's a similar option in postfix, or should I just back out the changes to those parts of the daily scripts? --Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: postfix equiv. of sendmail's -bH?
From: Garrett Wollman [EMAIL PROTECTED] Sent: Saturday, January 18, 2003 3:28 PM On Sat, 18 Jan 2003 10:25:53 -0500, Kutulu [EMAIL PROTECTED] said: I upgraded my system last night to the latest -CURRENT and noticed a change in the daily mail cleanup. Unfortunately, I'm not running sendmail, so now I'm getting: If you can come up with a good (silent) way to detect whether `sendmail -bH' is unsupported, I'd be happy to add that to the script. It's supposed to be able to deal with that case, but right now it can only detect the case where sendmail is being used, but not the host status cache. I'm not so much worried about the noise in my logs (I can just turn it off, which has also been pointed out to me a few times already). There's already a number of other daily periodic options postfix has you turn off, so that's a non-issue for me. And I'd fully accept the fact that, since I replaced a base-system daemon with a ports daemon, I'm the one who should be responsible for turning those off. I was just concerned that some useful task that used to occur nightly may now not be occurring, and if so, what I could do to make it occur again. I didn't see anything to even indicate that postfix has a host status cache, meaning the option is pretty pointless either way. I was just wondering if anyone who had run postfix longer than me knew for sure :) --Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dri-devel - HEADS-UP
From: Chuck Robey [EMAIL PROTECTED] Sent: Monday, December 30, 2002 5:02 PM The moral is, I think you need to rebuild/reinstall dri-devel if you're running FreeBSD-current. I have found that it's generally a good idea to rebuild any modules you have from ports (in my case it's ltmdm and radeon) when you upgrade the kernel. Especially with -CURRENT, the module interface could change at any time. Specifically, I had the same issue you did with ltmdm early last week, with the same solution (rebuild the port). ltmdm's pkg-message specifically tells you you'll have to do this, in fact. --K To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: no single user mode in installworld
From: Gernot A. Weber [EMAIL PROTECTED] Sent: Monday, December 23, 2002 3:58 PM Hi, I forgot to drop into single user mode before doing make installworld. The process finished without any obvious errors. I do this all the time when upgrading remotely. The primary issue with rebooting single-user is to prevent old versions of the userland binaries from trying to run against a new kernel. (Especially eg. ipfw, which changes all the time). But if you managed to get the installworld to run to completion and rebooted, you're probably fine. I'd read UPDATING to make sure there are no specific issues you might have to check on, and check to make sure all your normal daemons are active and nothing odd's showing in your logs. --K To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
hard drive panics help getting backtraces...
I'm having occasional panics when doing disk-intensive activities like a buildworld or portupgrade, and I'm having trouble getting useful backtraces. For some reason I can't get the kernel to write a dump out. Most recently, while updating the pkgdb, my system did this: Nov 19 14:47:19 basement syslogd: kernel boot file is /boot/kernel/kernel Nov 19 14:47:19 basement kernel: Slab at 0xc165bfd4, freei 1 = 0. Nov 19 14:47:19 basement kernel: panic: Duplicate free of item 0xc165b0cc from zone 0xc0a023c0(VMSPACE) Nov 19 14:47:19 basement kernel: Nov 19 14:47:19 basement kernel: Nov 19 14:47:19 basement kernel: syncing disks, buffers remaining... panic: bremfree: bp 0xc251d26c not locked Nov 19 14:47:19 basement kernel: Uptime: 1d1h20m15s Nov 19 14:47:19 basement kernel: Dumping 63 MB Nov 19 14:47:19 basement kernel: ata0: resetting devices .. Nov 19 14:47:19 basement kernel: panic: bremfree: bp 0xc250f3e8 not locked Nov 19 14:47:19 basement kernel: Uptime: 1d1h20m15s Nov 19 14:47:19 basement kernel: Terminate ACPI Nov 19 14:47:19 basement kernel: Automatic reboot in 15 seconds - press a key on the console to abort Nov 19 14:47:19 basement kernel: Rebooting... I have a dumpdev set up pointing to my swap space /dev/ad0s1b, I have DDB and DDB_UNATTENDED built into the kernel. I have a kernel with symbols in to use for getting a backtrace, if I could get a core dump from the kernel. What am I missing here? If neccessary, is there a way to force a core dump if I let it break into DDB and go sit at the console? --Mike Edenfield To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic when removing umass device (USB Camera)
From: Nate Lawson [EMAIL PROTECTED]
Sent: Thursday, November 14, 2002 2:13 PM
Try this patch for the BBB stall:
Index: /sys/cam/scsi/scsi_da.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.113
diff -u -r1.113 scsi_da.c
--- /sys/cam/scsi/scsi_da.c 17 Oct 2002 18:04:41 - 1.113
+++ /sys/cam/scsi/scsi_da.c 14 Nov 2002 19:04:40 -
@@ -416,7 +416,7 @@
* HP 315 Digital Camera
* PR: kern/41010
*/
- {T_DIRECT, SIP_MEDIA_REMOVABLE, HP, USB Camera*, *},
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, HP, USB CAMERA*, *},
/*quirks*/ DA_Q_NO_6_BYTE
}
};
I applied this patch and rebuilt my kernel w/ debugging symbols, so next
time it panic's I can get a core file.
The really good news is that this patch appears to have solved BOTH the BBB
stall errors *and* the panic:
umass0: at uhub1 port 4 (addr 4) disconnected
(da0:umass-sim0:0:0:0): lost device
(da0:umass-sim0:0:0:0): removing device entry
umass0: detached
Whatever the bug was appears to have been removing the da0 device entry, as
when the page fault did happen that message didn't appear on the console nor
did da0 go away. Now I get da0 (and da0s1, which also didn't happen before)
when the camera's on, and neither device when the camera's off.
Thanks *a lot* for this quick turnaround time. If you want me to back the
patch out and get a trace anyway (in case I'm now just covering up a bug
that still exists) I'd be more than happy to. Lemme know. I'm now going to
try actually mounting the device and moving files to/from it :)
--Mike Edenfield
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic when removing umass device (USB Camera)
From: Kutulu [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 8:58 PM Subject: Re: panic when removing umass device (USB Camera) I'm now going to try actually mounting the device and moving files to/from it :) Quick follow-up that this is working fine, including the file system unmounting itself when the camera goes to sleep. I'm rather impressed, even Windows 2000 complained about that one. :) --Mike Edenfield To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic when removing umass device (USB Camera)
I have an HP digital camera w/ CompactFlash that acts as a USB mass-storage device that's panic'ing my system when I remove it. If I do not load the umass driver, then the camera is detected as a simple generic ugen0 device, and I can safely add/remove the device at will. If I load the umass driver, the camera is correctly detected as a mass-storage device as such: umass0: HP USB DIGITAL CAMERA, rev 1.10/1.00, addr4 umass0: Residue incorrect, was 0, should've been 252 umass0: Residue incorrect, was 0, should've been 252 umass0: Residue incorrect, was 0, should've been 252 umass0: Residue incorrect, was 0, should've been 252 umass0: Residue incorrect, was 0, should've been 252 da0 at umass-sim0 bus 0 target 0 lun 0 da0: HP USB CAMERA 1.00 Removeable Direct Access SCSI-0 device da0: 1.000 MB/s transfers da0: 30 MB (62657 512 byte sectors: 64H 32S/T 30C) At this point, if I detach the camera (or, if the camera puts itself to sleep as it will do after 5 minutes of inactivity), I get the following errors: umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR (these are repeated 4 more times...) umass0: at uhub1 port 4 (addr 4) disconnected (da0: umass-sim0:0:0:)): lost device umass0: detached followed by a panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc10a fault code = supervisor read, page not present instruction pointer = 0x8:0xc01ea9d6 stack pointer = 0x10:0xc5e42b74 frame pointers = 0x10:0xc5e42b74 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def 32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL0 current process = 23 (usb0) kernel: type 12 trap, code=0 Stopped at device_get_nameunit+0x6:movl0x2c(%eax), %eax The really odd part is, if I haven't done anything between attaching and detaching, then I now get dropped into DDB and cannot continue without rebooting. However, if I *have* tried to access the device (even so much as cat /dev/da0) before detaching, I get the panic then get returned immediately to my console. The SCSI device disappears when I rescan the SCSI bus with camcontrol, and if I reattach the camera is doesn't come back, but otherwise the system keeps going like normal. (The actual devfs nodes /dev/da0 and /dev/umass0 are still there, however). Should I be able to remove this device at run-time, or am I trying to do something that's presently unsupported? And if so, what else do I need to do? Is there anything additional I need to add to my kernel, aside from usb, uhci, umass, scbus, da, and pass? Thanks for any assistance, and if there's more information I can provide please let me know. (I don't have backtraces because I have to copy stuff down on pen/paper and my hand cramped up after the panic :/ If those would be useful I'll try to find a space laptop serial cable.) --Mike Edenfield To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
From: Brian T.Schellenberger [EMAIL PROTECTED] Sent: Friday, February 01, 2002 7:31 PM I don't see that at all--the most distinctive characteristic to me of the Microsoft Windows Registry is that it tries to be a *single* place where *all* configuration information--both system and application--is written. If you ask Microsoft I'm pretty sure they'd tell you that's it's prime advantage and I claim that it's prime drawback. Either way, that's what most Actually, if you ask them *now* they will tell you it's a pain in the ass. Which is why they are moving away from the registry with .NET to application-specific manifests. Much like MDI, this is another great Microsoft 'innovation' that everyone copied until it became a de-facto standard... just in time for Micrsoft to declare it a failure. :x (Waiting for someone to suggest XML manifests for FreeBSD, and cringing). --K To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
